Mapping Fed Authn Methods to Authn Levels in OIF / SP

In my previous posts, I explained how to configure OIF/IdP to map Federation Authentication Methods to OAM Authentication Schemes for authentication and to allow an SP to request at runtime a user to be authenticated via a specific OAM Authentication Scheme.

In this article, I will now look at OIF/SP and how it can be set up to request a specific Federation Authentication Method to be used by the remote IdP Partner at runtime, to challenge the user.

Enjoy the reading!

Authentication Levels


OAM defines the notion of an Authentication Level in the Authentication Scheme. It indicates to OAM the level of strength of a particular scheme as a number (1, 2, 3...), and is used at runtime when an already authenticated user attempts to access a protected resource.

When a user is authenticated by OAM via an Authentication Scheme, OAM will create a session for that user, and will store in the session:

  • The Authentication Scheme name used to authenticate the user
  • The Authentication Level used for the authentication operation

When the user attempts to access a protected resource, OAM will perform the following:

  • Ensure that the user's session did not time out
  • Locate the resource in the OAM policy store
  • Determine which Authentication Policy is protecting the resource
  • Determine the Authentication Scheme used for this Authentication Policy
  • Get the Authentication Level for this Authentication Scheme
  • Compare the Authentication Level with the one that was used to create the user's session, during the earlier authentication operation
    • If the session's authentication level is equal or higher than the level of the current protected resource, then OAM will grant access to the user
    • Otherwise, OAM will challenge the user with the resource's Authentication Scheme

Federation Authentication Methods


The Federation SSO Response messages issued by an IdP/OP for the SAML 2.0/SAML 1.1/OpenID 2.0 contain a Federation Authentication Method indicating how the user was challenged at the IdP.

By default, when OIF/SP consumes an SSO Response, an OAM session will be created with the session's Authentication Level set to the Authentication Scheme's Authentication Level. This is rather static and ignores how the user was challenged at the IdP.

The Federation Authentication Method contained in the SSO Response indicates how the user was identified at the IdP, and it is sometimes preferable to base the OAM session's Authentication Level on that information instead of relying on the level contained in Federation Authentication Scheme.

When consuming Federation SSO Responses, OIF/SP allows the dynamic mapping of Federation Authentication Methods contained in the response to custom Authentication Levels, which will result in an OAM session being created with a level that reflects how the user was challenged at the IdP.

WLST Commands


OIF/SP can be configured to map a specific Federation Authentication Method to an Authentication Level via:

  • An IdP Partner Profile which would apply to all IdP Partners bound to this profile
  • An IdP Partner, which in this case would only apply to this partner

The OIF WLST commands that can be used are:

  • addIdPPartnerProfileAuthnMethod() which will map the specified Federation Authentication Method in a specific IdP Partner Profile to the given level. It accepts the following parameters:
    • partnerProfile: name of the IdP Partner Profile
    • authnMethod: the Federation Authentication Method to map
    • authnLevel: the level to be mapped to the Federation Authentication Method
  • addIdPPartnerAuthnMethod() which will configure the specified IdP Partner entry to map the specified Federation Authentication Method to the given level. It accepts the following parameters:
    • partner: name of the IdP Partner
    • authnMethod: the Federation Authentication Method to map
    • authnLevel: the level to be mapped to the Federation Authentication Method

Test


Setup

In this setup, OIF is acting as an SP and is integrated with a remote SAML 2.0 IdP partner identified by AcmeIdP:

  • By default, OIF/SP is not configured to request any Federation Authentication Method
  • Two resources exist at OAM/OIF/SP and are protected by WebGate:
    • Resource1 is protected via the FederationScheme which is set to level 2
    • Resource2 is protected via the LDAPScheme which is set to level 3
  • The remote IdP supports the following Federation Authentication Methods
    • urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport (default method indicated by the IdP out of band)
    • urn:oasis:names:tc:SAML:2.0:ac:classes:X509

In the following tests, I will perform Federation SSO with OIF/SP configured to and then access both resources:

  • Perform Federation SSO with the IdP challenging the user via username/password
  • Perform Federation SSO with the IdP challenging the user via X.509 certificate
  • Configure OIF/SP to map urn:oasis:names:tc:SAML:2.0:ac:classes:X509 to level 3
  • Perform Federation SSO with the IdP challenging the user via username/password
  • Perform Federation SSO with the IdP challenging the user via X.509 certificate

SSO with Username/Password

The IdP will challenge the user with its default authentication mechanism (in this case with a mechanism mapped to urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport)

The SAML 2.0 SSO Response would be similar to:

<samlp:Response ...>
    <saml:Issuer ...>https://acmeidp.com</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer ...>https://acmeidp.com</saml:Issuer>
        <dsig:Signature>
            ...
        </dsig:Signature>
        <saml:Subject>
            <saml:NameID ...>bob@oracle.com</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData .../>
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions ...>
            <saml:AudienceRestriction>
                <saml:Audience>https://sp.com</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2014-03-21T20:53:55Z" SessionIndex="id-6i-Dm0yB-HekG6cejktwcKIFMzYE8Yrmqwfd0azz" SessionNotOnOrAfter="2014-03-21T21:53:55Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>
                      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
                </saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
    </saml:Assertion>
</samlp:Response>

After OIF/SP consumes the SAML 2.0 Assertion and creates an OAM session with the Authentication Level set to the FederationScheme's Authentication Level (2), because no mapping exists for urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport:

  • When accessing Resource1, access will be granted, because the OAM session's level is 2, which is equal to the scheme's level protecting that resource (2)
  • When accessing Resource2, OAM will challenge the user via LDAPScheme, because the OAM session's level is 2, which is lower than the scheme's level protecting that resource (3)

SSO with X.509 Certificate

The IdP will challenge the user X.509 certificate (mapped to urn:oasis:names:tc:SAML:2.0:ac:classes:X509)

The SAML 2.0 SSO Response would be similar to:

<samlp:Response ...>
    <saml:Issuer ...>https://acmeidp.com</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer ...>https://acmeidp.com</saml:Issuer>
        <dsig:Signature>
            ...
        </dsig:Signature>
        <saml:Subject>
            <saml:NameID ...>bob@oracle.com</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData .../>
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions ...>
            <saml:AudienceRestriction>
                <saml:Audience>https://sp.com</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2014-03-21T20:53:55Z" SessionIndex="id-6i-Dm0yB-HekG6cejktwcKIFMzYE8Yrmqwfd0azz" SessionNotOnOrAfter="2014-03-21T21:53:55Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>
                     urn:oasis:names:tc:SAML:2.0:ac:classes:X509
                </saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
    </saml:Assertion>
</samlp:Response>

After OIF/SP consumes the SAML 2.0 Assertion and creates an OAM session with the Authentication Level set to the FederationScheme's Authentication Level (2), because no mapping exists for urn:oasis:names:tc:SAML:2.0:ac:classes:X509:

  • When accessing Resource1, access will be granted, because the OAM session's level is 2, which is equal to the scheme's level protecting that resource (2)
  • When accessing Resource2, OAM will challenge the user via LDAPScheme, because the OAM session's level is 2, which is lower than the scheme's level protecting that resource (3)

Mapping X.509 Fed Authn Method to Level 3

To configure OIF/SP to map urn:oasis:names:tc:SAML:2.0:ac:classes:X509 to the Authentication Level 3, I will use the addIdPPartnerAuthnMethod() to configure the IdP Partner:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()
  • Execute the addIdPPartnerAuthnMethod() command:
    addIdPPartnerAuthnMethod("AcmeIdP", "3")
  • Exit the WLST environment:
    exit()

SSO with Username/Password

The IdP will challenge the user with its default authentication mechanism (in this case with a mechanism mapped to urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport)

After OIF/SP consumes the SAML 2.0 Assertion and creates an OAM session with the Authentication Level set to the FederationScheme's Authentication Level (2), because no mapping exists for urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport:

  • When accessing Resource1, access will be granted, because the OAM session's level is 2, which is equal to the scheme's level protecting that resource (2)
  • When accessing Resource2, OAM will challenge the user via LDAPScheme, because the OAM session's level is 2, which is lower than the scheme's level protecting that resource (3)

SSO with X.509 Certificate

The IdP will challenge the user X.509 certificate (mapped to urn:oasis:names:tc:SAML:2.0:ac:classes:X509)

After OIF/SP consumes the SAML 2.0 Assertion and creates an OAM session with the Authentication Level set to 3, because a mapping exists for urn:oasis:names:tc:SAML:2.0:ac:classes:X509:

  • When accessing Resource1, access will be granted, because the OAM session's level is 3, which is greater than the scheme's level protecting that resource (2)
  • When accessing Resource2, access will be granted, because the OAM session's level is 3, which is equal to the scheme's level protecting that resource (3)

In the next article, I will show how to integrate Google Apps as an SP and OIF as an IdP.
Cheers,
Damien Carru

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Damien Carru is a member of the Oracle Identity Management organization, focusing on Federation and SSO. This blog will cover Federation use cases involving Oracle Access Manager, Oracle Identity Federation and Oracle Security Token Service

Search

Categories
Archives
« August 2015
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today