sso配置
1.idp安装，配置 nameid为啥没有生效
attribute-filter.xml配置文件没有写对

<!--value="https://signin.aliyun.com/xxxxxx/saml/SSO" 要和主账号ID的sso配置相同 -->
    <AttributeFilterPolicy id="aliyun">
        <PolicyRequirementRule xsi:type="Requester" value="https://signin.aliyun.com/xxxxxx/saml/SSO" />
            <AttributeRule attributeID="mail">
                <PermitValueRule xsi:type="ANY" />
            </AttributeRule>
    </AttributeFilterPolicy>

2.域名绑定idp.xxxx.com
3.阿里云sso后台配置用户sso配置，开启auth登录
4.企业后台 配置jaas认证用户，添加用户账号和密码

idp主动登录UnsolicitedSSOConfiguration，绕过ram登录页面
web登录阿里云的auth
UnsolicitedSSO官网的定义 就是idp发起saml响应信息给到sp提供商，
官网资料介绍如下：

SAML 1.x
In older Shibboleth versions, the lack of a request message in SAML 1.x was supplemented with a simple request format defined in the Shibboleth Protocol Specification.

Out of the box, requests are handled at https://hostname/idp/profile/Shibboleth/SSO (replacing hostname with the location of your IdP) and the following query string parameters can be used:

providerId
the name (i.e., the entityID) of the service provider
shire
the URL of the SAML 1.1 response location at the SP (called the "Assertion Consumer Service")
target
a target resource at the SP, or a state token generated by an SP to represent the resource
time (optional)
a timestamp to help with stale request detection
Formally speaking, this is not IdP-initiated SSO; it's a proprietary request to the IdP that results in a response to the SP. If you refer back to the initial discussion above, you can see that that's actually the definition of IdP-initiated SSO.

SAML 2.0
The original protocol was adapted so that it can be used to trigger SAML 2.0 SSO in addition to legacy SAML 1.x responses. The two protocols are not supported at the same location in the IdP; that is, you can't send the request to one location and have the IdP figure out which protocol to use. It's simply an alternative request format that requires the identified SP support SAML 2.0.

Out of the box, this endpoint can be found at https://hostname/idp/profile/SAML2/Unsolicited/SSO (replacing hostname with the location of your IdP) and the following parameters can be used:

providerId
the name (i.e., the entityID) of the service provider
shire (optional)
URL of the SAML 2.0 response location at the SP (the "Assertion Consumer Service"), but can be omitted in favor of the IdP picking the default ACS location from the SP's metadata
target (optional)
corresponds to RelayState in the SAML 2.0 protocol, but can generally be omitted
time (optional)
a timestamp to help with stale request detection
As you can see, this is the same protocol as before, but with more optional parameters, reflecting how we would have designed the protocol if we were starting from scratch today. Protocol syntax is compatible with the original so that existing links can be easily adapted and used, despite the fact that the terminology is outdated (you don't want to know the origin of the name "shire", but it doesn't involve hobbits).

Examples
The examples assume the default locations supported out of the box, which should rarely need to be adjusted, and an IdP located at idp.example.org.

They also assume proper metadata is loaded into the IdP. There is nothing special about the metadata required to use this feature, it's the same metadata required for any use of the corresponding SP, and if you have to create that by hand because you're working with a deficient partner and/or outside the context of a federation, see other topics and examples to explore how to do that.

Given an SP named "https://sp.example.org/shibboleth", requesting SAML 2.0 SSO to the SP's default endpoint in metadata is just a link to:

https://idp.example.org/idp/profile/SAML2/Unsolicited/SSO?providerId=https%3A%2F%2Fsp.example.org%2Fshibboleth

A real world example of a non-Shibboleth SP that also requires a target parameter to identify a specific service to invoke (the names have been sanitized to protect the ignorant):

https://idp.example.org/idp/profile/SAML2/Unsolicited/SSO?providerId=http%3a%2f%2ffederation.morons.com%2fadfs%2fservices%2ftrust&target=rpid%3dhttps%253A%252F%252Ffederationx.morons.com%252FClaimsAwareHelper%252F%26wctx%3dTWN-EE-ER"

The example above is something you'll run into occasionally: the doubly-encoded value. When an SP is sufficiently broken, it may require query parameters that are themselves passed as values of the target parameter (as shown above, where the target value is a query parameter named "rpid" and with the value of another URL). The URL parameter to which the "rpid" name is assigned is URL-encoded, and then the entire name/value pair is URL-encoded for inclusion in the "target" parameter.

It's not common to have to provide the "shire" parameter in the SAML 2.0 case, but it may be needed if a single SP has development and production versions distinguished by SAML endpoint; the parameter would tell the IdP where to send the browser after logging in, and thus which environment to access.

providerId
the name (i.e., the entityID) of the service provider
注意这里的targer参数
target
a target resource at the SP, or a state token generated by an SP to represent the resource

target参数是URL要urlencode下，可以拼出来idp登录页面的路径如下：

https://idp.domaim.cn/idp/profile/SAML2/Unsolicited/SSO?providerId=https://signin.aliyun.com/XXXXXXX/saml/SSO&target=
https://signin.aliyun.com/oauth2/v1/auth?client_id=XXXXXXXX&redirect_uri=http://domain.com/login/oauth2/code/aliyun&resopnse_type=code

Web应用通过浏览器将用户重定向到阿里云OAuth 2.0服务从而获取授权码参数说明
idp.domaim.cn：idp认证系统
XXXXXXX： 阿里云主账号accountId
domain.com：阿里其他应用服务
redirect_uri：auth2.0登录配置的登录回调地址