When a Portlet is challenged to authenticate itself to a Web Service Provider using a SAML assertion, either it can do so on its own (authenticating as itself, on other words), or it may wish to do so acting as a delegate of a user.
In the former case, there is no special requirement. The Portlet can authenticate itself to an IdP without unusual machinations. In the latter case, the Portlet will generally need to obtain a SAML assertion from an IdP that it can use to authenticate to that IdP on the user's behalf. This is a fairly standard approach in Liberty ID-WSF profiles. The complications arise from the relationship between the Portlet and the Portal to which the user originally authenticated.
Simple Case: Portal == Portlets
If the Portal and its Portlets share an SP identity in SAML terms, and likely an underlying private key, then the assertion(s) issued to the Portal will be usable by the Portlets, and the Portal may communicate the assertion(s) to the Portlets by whatever method is convenient.
Complex Case: Portal != Portlets
If, however, the ability to authenticate to the IdP (and subsequently to a WSP) as a delegate must be constrained or audited at the Portlet level, then each Portlet must be associated with a unique SAML entityID. This does not imply either one or multiple private keys; that is subject to deployment policy. But in such a case, the Portlet's acquisition of a suitable token that it can use at the IdP may be more involved.
If the original SAML SSO response to the Portal is optimized to include a suitable assertion, then the Portlet may be able to obtain it directly from the Portal (or from the security context of the user with the Portal). If not, then an additional round trip is necessary to obtain an assertion from the IdP. In this situation, the Portal is responsible for acquiring the next assertion in the chain, which it will supply to the Portlet.
Assuming the existence of a request mechanism by which the Portlet can identify itself and ask the Portal to supply an assertion for it to use to authenticate to the IdP as the user, we propose the following sequence:
1. Portlet Requests Assertion From Portal
This step is implementation-specific but assumes the existence of an API or similar mechanism by which a Portlet can ask the Portal for an assertion that it can present to the user's Identity Provider to authenticate itself in step 4 of the ID-WSF ECP SSO Profile.
We further require that for subsequent auditing purposes that a record of the Portal's involvement will be tracked in an implementation-specific manner in the returned assertion. This is necessary so that the Portlet's subsequent requests will allow the assertions returned to it to contain the Portal as a "transited provider", per section 6 of the ID-WSF Security Mechanism Profile of SAML.
2. Portal Issues <samlp:AuthnRequest> to Identity Provider
See step 1 of the ID-WSF SAML Token Service Profile (section 6.4.2). This is a SOAP request to the IdP, governed by additional ID-WSF profiles of SOAP and WS-Security that allow a SAML assertion to be used interoperably to authenticate the Portal to the IdP on the user's behalf.
We do not formally constrain the possibilities for authenticating this exchange, but expect that the most likely security mechanisms used will be urn:liberty:security:2006-08:ClientTLS:peerSAMLV2 and urn:liberty:security:2006-08:TLS:SAMLV2. In both cases, the Portal uses a private key to satisfy the IdP of its right to use the authenticating assertion, but in the former case mutual TLS authentication is used, while in the latter case the SOAP message is digitally signed.
The purpose of this request is to acquire a token with the following characteristics:
- Its
<saml:Subject>identifies the user (possibly in a privacy preserving manner). - A "bearer"
<saml:SubjectConfirmation>element is included granting the Portal the right to pass the assertion on to one or more Portlets. - Additional
<saml:SubjectConfirmation>elements are included as necessary to grant one or more Portlets the right to authenticate back to the IdP as the user. The confirmation method is up to the Identity Provider, but is likely to be "holder-of-key". - Its
<saml:AudienceRestriction>condition enumerates one or more Portlets and the Identity Provider itself as acceptable relying parties.
These characteristics can be enumerated using the content of the request message, per section 6.4.3.1 of the ID-WSF SAML Token Service Profile, or can be established out of band (or a combination of both).
3. Identity Provider Identifies Principal
See step 2 of the ID-WSF SAML Token Service Profile (section 6.4.2). This is the "Portal as User" authentication step, and processes the Portal's request for a proxy authentication token to pass along to the Portlet. 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 Portal.
Conceptually the Portal is acquiring a token to authenticate to the Portlet, but the underlying goal is simply to acquire a token the Portlet can use in making its own requests.
4. Identity Provider Issues <samlp:Response> to Portal
See step 3 of the ID-WSF SAML Token Service Profile (section 6.4.2). This is a SOAP response to the Portal containing the proxied authentication token(s) with which the Portlet will be able to authenticate to the WSP as the user.
5. Portal Returns Assertion to Portlet
The final step is implementation-specific, but provides the returned assertion to the Portlet in response to the request in step 1. Formally, the Portal is "authenticating" to the Portlet in returning the assertion to it, and the Portlet MAY enforce the standard SAML processing rules against the returned assertion. It might also choose to implicitly trust the Portal and the communication channel with it.