Shibboleth搭建idp之Unsolicited/SSO

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登入配置的登入回調位址