...
- SAML 2.0 Web Browser SSO Profile
- This is the basic Shibboleth solution and will bootstrap the second profile by decorating the assertion returned with additional content to enable delegated use.
- ID-WSF Enhanced Client or Proxy SSO Profile
- This a profile for SAML-based authentication that is suited to non-browser software and can be related to the initial SSO event to create an auditable chain of activity.
- ID-WSF SAML Token Service Profile
- This is a back-channel profile between a client and an Identity Povider to allow a client to explicitly request an assertion.
- SAML V2.0 Condition for Delegation Restriction
- This is an extension for codifying the inclusion of delegation chains in SAML assertions in a mandatory-to-process fashion.
Properly composed, these specifications and their dependencies are sufficient to address the use case. SAML includes a basic ECP profile that is very similar to the Liberty version referenced above, but was designed for passing through browser-friendly login UI to a client, and not for server-side authentication to an IdP. The Liberty version relies on SOAP and a set of Liberty specifications and OASIS standards between the client (in this case the Portal/Portlet) and the IdP, which is a better framework for server-side authentication.
...
In all of the tokens, the subject and the statements refer to the user, and never the proxying delegate systems. In the case of a single proxying step, the proxying system is identified inside the subject confirmation of the assertion. When proxying passes through an additional hop (including a Portal/Portlet hand-off), the previous proxies are moved into the assertion's advice section in a syntax defined by LibertyThe delegates are identified in a mandatory-to-process SAML condition.
Solution Sequence
| Table of Contents | ||
|---|---|---|
|
...
See step 3 of the Web Browser SSO Profile (section 4.1.3.3). Various cues MAY be included in this request from the portal to optimize the rest of the flows. For example, one or more <saml:Audience> elements can be included to indicate that the Portal or Portlet(s) wish to obtain an assertion they can use as a proxy delegate for the user.
1.4. Identity Provider Identifies Principal
...
See step 5 of the ID-WSF ECP SSO Profile (section 6.3.2). This is the "Portlet as User" authentication step, and processes the Portlet's request for a proxy delegated authentication token to use at the WSP that issued the <samlp:AuthnRequest>. Policy may be applied here to control the issuance of such tokens, and XML Encryption can be used to hide all user information from the Portlet.
...
See step 6 of the ID-WSF ECP SSO Profile (section 6.3.2). This is a SOAP response to the Portlet containing the SAML response targeted to the WSP containing the proxied delegated authentication token with which the Portlet will be able to authenticate to the WSP as the user.
Note that this delegated token may itself contain the capability to authenticate back to the IdP via a recursive act of delegation. This is orthogonal to the delegation that takes place to the WSP.
2.7. Portlet Forwards <samlp:Response> to Web Service Provider
See step 7 of the ID-WSF ECP SSO Profile (section 6.3.2). This delivers the proxy delegated authentication token to the WSP as a bearer assertion, analagous to the process by which a browser User Agent authenticates the user to a web site. A WSP can assess the act of proxying delegation and respond appropriately, or ignore the distinction entirely.
2.8. Web Service Provider Responds to Portlet
...