Infocard Authentication Scenario Details
From Project Concordia
Contents |
Scenario - Infocard Authentication followed by SAML/WS-Federation SSO
This use case is characterized by a user authenticating to an IdP using an Infocard (in various permutations of managed or personal cards), the fact of that authentication communicated to a downstream Relying Party through the SAML 2.0 protocol.
There are two aspects of convergence demonstrated in this scenario
- composability between Infocard & SAML/WS-Federation
- cross-system authentication policy URIs
In accepting an assertion from an IDP, the RP may care about the specifics of the Infocard authentication (e.g. password) or the derived assurance level (e.g. Level 2, etc) or the derived characteristics (e.g. Phishing resistance, anonymity, etc)
The IIW consensus was that, for this IOP at least, we should restrict ourselves to the simplest option, and define the following URIs (or equivalent) to describe the specifics of the Infocard authentication mechanism, and not attempt to categorize assurance or characteristics.
http://projectconcordia.org/rsainterop/authnmech/personal http://projectconcordia.org/rsainterop/authnmech/managed/password http://projectconcordia.org/rsainterop/authnmech/managed/kerberos http://projectconcordia.org/rsainterop/authnmech/managed/x509 http://projectconcordia.org/rsainterop/authnmech/managed/personal
If the ultimate RP wishes to express this sort of policy, the federation protocol must support both of
- allowing the RP to specify its requirements in its request to the IDP:
- in a samlp:AuthnRequest/samlp:RequestedAuthnContext
- in WS-SecurityPolicy but requesting a claim with a matching name
- allowing the IDP to describe the authentication performed in the assertion issued:
- in a samlp:Response/saml:Assertion/saml:AuthnContext
- in a RSTR/saml:Assertion/saml:AuthnContext or RSTR/saml1:Assertion/saml1:AuthenticationStatement/@AuthenticationMethod
Infocard and SAML 2.0 SSO
Flow
Presumes that the appropriate set of managed & personal cards are installed on client. The managed cards should have different authentication mechanisms associated with them, and in Infocard terms, should have support for one or more specific claim types corresponding to the authentication mechanisms.
A pair of predefined claims for first and last name will also be used, and mapped into SAML attributes.
- User presents themself to a SAML SP.
- SAML SP redirects them to SAML IDP using samlp:AuthnRequest (specifying the desired Infocard authentication mechanism in its samlp:RequestedAuthnContext element) and requests they be authenticated.
- SAML IDP authenticates user via Infocard & WS-Trust such that the SAML SP's specified authentication requirement is satisfied. The SAML IDP will convert the SAML SP's specified requirement into the corresponding claim type(s) in order to drive appropriate card selection. If the specified mechanism implies that a managed card be used, an appropriate Infocard MCP will be selected (as represented by an installed card).
- If an Infocard MCP is used, the identity selector will send an RST which, after authenticating the user, will respond with an RSTR.
- Identity selector will send RSTR to the Infocard RP/SAML IDP.
- SAML IDP sends the user back to the SAML SP, specifying the authentication context extracted from the RSTR token. (If the token is a SAML 2.0 assertion, the SAML IDP can simply copy the saml:AuthenticationContext element from the token into the newly constructed assertion to be sent to the SAML SP)
- User is logged into original SAML SP with appropriate privileges.
Messages
For simplicity, only a portion of the unencoded messages are shown.
The SAML RP wants the user to be authenticated with an X.509 cert to a managed card provider.
1. SAML SP sends samlp:AuthnRequest to SAML IDP via HTTP-Redirect binding, specifying the desired authentication mechanism.
<samlp:AuthnRequest> <samlp:RequestedAuthnContext Comparison="exact"> <samlp:AuthnContextClassRef> http://projectconcordia.org/rsainterop/authnmech/managed/x509 </samlp:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest>
2. SAML IDP/Infocard RP invokes Selector
<OBJECT type="application/x-informationCard" name="xmlToken"> <PARAM Name="RequiredClaims" value= "http://projectconcordia.org/rsainterop/authnmech/managed/x509 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"/> </OBJECT>
3. Selector compares available cards to Infocard RP's requirements. Sends RST to appropriate MCP. X.509 mechanism implicitly expressed through the endpoint to which the RST is sent.
<wst:RequestSecurityToken> </wst:RequestSecurityToken>
4. MCP creates SAML Assertion for claims and sends in RSTR (example shown is SAML 2.0.):
<wst:RequestSecurityTokenResponse>
<saml:Assertion ID="foo">
<saml:Subject/>
<saml:Conditions>
<saml:AudienceRestriction>
<saml:Audience>http://www.inforcardrp.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement>
<saml:AuthnContext>
<saml:AuthnContextClassRef>
http://projectconcordia.org/rsainterop/authnmech/managed/x509
</saml:AuthnContextClassRef>
<saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<!-- this duplicates authn context above -->
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="http://projectconcordia.org/rsainterop/authnmech/managed/x509">
<saml:AttributeValue>
http://projectconcordia.org/rsainterop/authnmech/managed/x509
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims"
Name="givenname">
<saml:AttributeValue>John</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims"
Name="surname">
<saml:AttributeValue>Doe</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</wst:RequestSecurityTokenResponse>
5. Selector forwards RSTR to Infocard RP
<wst:RequestSecurityTokenResponse> <saml:Assertion ID="foo"> <!-- same as above --> </saml:Assertion> </wst:RequestSecurityTokenResponse>
6. Infocard RP responds to original SAML SP (with POST Binding?)
<samlp:Response>
<saml:Assertion ID="bar"> <!-- note this is a different assertion -->
<saml:Subject/>
<saml:Conditions>
<saml:AudienceRestriction>
<saml:Audience>http://www.samlrp.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement>
<saml:AuthnContext>
<saml:AuthnContextClassRef>
http://projectconcordia.org/rsainterop/authnmech/managed/x509
</saml:AuthnContextClassRef>
<saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<!-- this duplicates authn context above -->
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="http://projectconcordia.org/rsainterop/authnmech/managed/x509">
<saml:AttributeValue>
http://projectconcordia.org/rsainterop/authnmech/managed/x509
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims"
Name="givenname">
<saml:AttributeValue>John</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims"
Name="surname">
<saml:AttributeValue>Doe</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
InfoCard and WS-Federation SSO
Flow
Presumes that the appropriate set of managed & personal cards are installed on client. The managed cards should have different authentication mechanisms associated with them, and in InfoCard terms, should have support for one or more specific claim types corresponding to the authentication mechanisms.
- User presents themself to a WS-Federation Relying Party.
- WS-Fed redirects them to WS-Fed Identity Provider and requests they be authenticated.
- WS-Fed IP authenticates user via Infocard such that the WS-Fed RP's authentication requirement is satisfied. The WS-Fed IP will convert the relying party's requirements into the corresponding claim type(s) in order to drive appropriate card selection. If the specified mechanism implies that a managed card be used, an appropriate InfoCard Identity Provider will be available to the user (as represented by an installed managed card).
- If a managed InfoCard is used, the identity selector will send an RST which, after authenticating the user, will respond with an RSTR.
- Identity selector will send the issued token to the InfoCard RP/WS-Fed IP.
- WS-Fed IDP sends the user back to the WS-Fed RP, specifying the authentication context extracted from the issued token. (If the token is a SAML 2.0 assertion, the WS-Fed IP can simply copy the saml:AuthenticationContext element from the token into the newly constructed assertion to be sent to the WS-Fed RP).
- User is logged into original WS-Fed RP with appropriate privileges. For demonstration purposes, the WS-Fed RP should display the claims from the SAML 2.0 token and the authentication context information contained in the token.
- In steps 2 and 3, if possible, the WS-Fed RP should communicate its authentication requirement to the WS-Fed IP using the WS-Fed WAuth feature and the WS-Fed IP should use this information to request an InfoCard using an appropriate authentication method. The authentication requirement is to be communicated using one of the Concordia Interop authentication context URIs, such as http://projectconcordia.org/rsainterop/authnmech/managed/x509. If no authentication requirement is communicated via WAuth, the WS-Fed IP should still allow the user to authenticate with an InfoCard, and construct a SAML 2.0 token that communicates the authentication method used using SAML authentication context. If the WS-Fed RPs authentication requirements were not met, it should display an appropraite error message.
Messages
The messages exchanged use the standard WS-Federation 1.1 Passive Requestor Profile. They will carry SAML 2.0 tokens equivalent to those described in the SAML 2.0 protocol scenario.
Complete Example SAML 2.0 Assertion
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_284f52f160b84fc784753c5c5f140cdd" Version="2.0" IssueInstant="2008-01-28T23:24:53Z"> <saml:Issuer>https://samlidp.com</saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://samlidp.com" SPNameQualifier="https://samlsp.com"> eyiyietyietyilwruiyueehwersfjk </saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData Address="75.171.155.30" NotOnOrAfter="2008-01-28T23:29:53Z"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2008-01-28T23:24:53Z" NotOnOrAfter="2008-01-28T23:29:53Z"/> <saml:AuthnStatement AuthnInstant="2008-01-28T23:24:53Z"> <saml:SubjectLocality Address="75.171.155.30"/> <saml:AuthnContext> <saml:AuthnContextClassRef> http://projectconcordia.org/rsainterop/authnmech/managed/x509 </saml:AuthnContextClassRef> <saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="http://projectconcordia.org/rsainterop/authnmech/managed/x509"> <saml:AttributeValue> http://projectconcordia.org/rsainterop/authnmech/managed/x509 </saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" Name="givenname"> <saml:AttributeValue>John</saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" Name="surname"> <saml:AttributeValue>Doe</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>
