Fed Authentication Methods in OIF / IdP

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Posted by Damien Carru on Oracle Blogs See other posts from Oracle Blogs or by Damien Carru
Published on Wed, 28 May 2014 15:51:36 +0000 Indexed on 2014/05/28 21:48 UTC
Read the original article Hit count: 655

Filed under:

This article is a continuation of my previous entry where I explained how OIF/IdP leverages OAM to authenticate users at runtime:

  • OIF/IdP internally forwards the user to OAM and indicates which Authentication Scheme should be used to challenge the user if needed
  • OAM determine if the user should be challenged (user already authenticated, session timed out or not, session authentication level equal or higher than the level of the authentication scheme specified by OIF/IdP…)
  • After identifying the user, OAM internally forwards the user back to OIF/IdP
  • OIF/IdP can resume its operation

In this article, I will discuss how OIF/IdP can be configured to map Federation Authentication Methods to OAM Authentication Schemes:

  • When processing an Authn Request, where the SP requests a specific Federation Authentication Method with which the user should be challenged
  • When sending an Assertion, where OIF/IdP sets the Federation Authentication Method in the Assertion

Enjoy the reading!

Overview

The various Federation protocols support mechanisms allowing the partners to exchange information on:

  • How the user should be challenged, when the SP/RP makes a request
  • How the user was challenged, when the IdP/OP issues an SSO response

When a remote SP partner redirects the user to OIF/IdP for Federation SSO, the message might contain data requesting how the user should be challenged by the IdP: this is treated as the Requested Federation Authentication Method.

OIF/IdP will need to map that Requested Federation Authentication Method to a local Authentication Scheme, and then invoke OAM for user authentication/challenge with the mapped Authentication Scheme. OAM would authenticate the user if necessary with the scheme specified by OIF/IdP.

Similarly, when an IdP issues an SSO response, most of the time it will need to include an identifier representing how the user was challenged: this is treated as the Federation Authentication Method.

When OIF/IdP issues an Assertion, it will evaluate the Authentication Scheme with which OAM identified the user:

  • If the Authentication Scheme can be mapped to a Federation Authentication Method, then OIF/IdP will use the result of that mapping in the outgoing SSO response:
    • AuthenticationStatement in the SAML Assertion
    • OpenID Response, if PAPE is enabled
  • If the Authentication Scheme cannot be mapped, then OIF/IdP will set the Federation Authentication Method as the Authentication Scheme name in the outgoing SSO response:
    • AuthenticationStatement in the SAML Assertion
    • OpenID Response, if PAPE is enabled

Mappings

In OIF/IdP, the mapping between Federation Authentication Methods and Authentication Schemes has the following rules:

  • One Federation Authentication Method can be mapped to several Authentication Schemes
  • In a Federation Authentication Method <-> Authentication Schemes mapping, a single Authentication Scheme is marked as the default scheme that will be used to authenticate a user, if the SP/RP partner requests the user to be authenticated via a specific Federation Authentication Method
  • An Authentication Scheme can be mapped to a single Federation Authentication Method

Let’s examine the following example and the various use cases, based on the SAML 2.0 protocol:

  • Mappings defined as:
    • urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport mapped to
      • LDAPScheme, marked as the default scheme used for authentication
      • BasicScheme
    • urn:oasis:names:tc:SAML:2.0:ac:classes:X509 mapped to
      • X509Scheme, marked as the default scheme used for authentication
  • Use cases:
    • SP sends an AuthnRequest specifying urn:oasis:names:tc:SAML:2.0:ac:classes:X509 as the RequestedAuthnContext: OIF/IdP will authenticate the use with X509Scheme since it is the default scheme mapped for that method.
    • SP sends an AuthnRequest specifying urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport as the RequestedAuthnContext: OIF/IdP will authenticate the use with LDAPScheme since it is the default scheme mapped for that method, not the BasicScheme
    • SP did not request any specific methods, and user was authenticated with BasisScheme: OIF/IdP will issue an Assertion with urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport as the FederationAuthenticationMethod
    • SP did not request any specific methods, and user was authenticated with LDAPScheme: OIF/IdP will issue an Assertion with urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport as the FederationAuthenticationMethod
    • SP did not request any specific methods, and user was authenticated with BasisSessionlessScheme: OIF/IdP will issue an Assertion with BasisSessionlessScheme as the FederationAuthenticationMethod, since that scheme could not be mapped to any Federation Authentication Method (in this case, the administrator would need to correct that and create a mapping)

Configuration

Mapping Federation Authentication Methods to OAM Authentication Schemes is protocol dependent, since the methods are defined in the various protocols (SAML 2.0, SAML 1.1, OpenID 2.0).

As such, the WLST commands to set those mappings will involve:

  • Either the SP Partner Profile and affect all Partners referencing that profile, which do not override the Federation Authentication Method to OAM Authentication Scheme mappings
  • Or the SP Partner entry, which will only affect the SP Partner

It is important to note that if an SP Partner is configured to define one or more Federation Authentication Method to OAM Authentication Scheme mappings, then all the mappings defined in the SP Partner Profile will be ignored.

Authentication Schemes

As discussed in the previous article, during Federation SSO, OIF/IdP will internally forward the user to OAM for authentication/verification and specify which Authentication Scheme to use.

OAM will determine if a user needs to be challenged:

  • If the user is not authenticated yet
  • If the user is authenticated but the session timed out
  • If the user is authenticated, but the authentication scheme level of the original authentication is lower than the level of the authentication scheme requested by OIF/IdP

So even though an SP requests a specific Federation Authentication Method to be used to challenge the user, if that method is mapped to an Authentication Scheme and that at runtime OAM deems that the user does not need to be challenged with that scheme (because the user is already authenticated, session did not time out, and the session authn level is equal or higher than the one for the specified Authentication Scheme), the flow won’t result in a challenge operation.

Protocols

SAML 2.0

The SAML 2.0 specifications define the following Federation Authentication Methods for SAML 2.0 flows:

  • urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
  • urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
  • urn:oasis:names:tc:SAML:2.0:ac:classes:Telephony
  • urn:oasis:names:tc:SAML:2.0:ac:classes:MobileOneFactorUnregistered
  • urn:oasis:names:tc:SAML:2.0:ac:classes:PersonalTelephony
  • urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
  • urn:oasis:names:tc:SAML:2.0:ac:classes:MobileOneFactorContract
  • urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard
  • urn:oasis:names:tc:SAML:2.0:ac:classes:Password
  • urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocolPassword
  • urn:oasis:names:tc:SAML:2.0:ac:classes:X509
  • urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
  • urn:oasis:names:tc:SAML:2.0:ac:classes:PGP
  • urn:oasis:names:tc:SAML:2.0:ac:classes:SPKI
  • urn:oasis:names:tc:SAML:2.0:ac:classes:XMLDSig
  • urn:oasis:names:tc:SAML:2.0:ac:classes:SoftwarePKI
  • urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
  • urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  • urn:oasis:names:tc:SAML:2.0:ac:classes:SecureRemotePassword
  • urn:oasis:names:tc:SAML:2.0:ac:classes:NomadTelephony
  • urn:oasis:names:tc:SAML:2.0:ac:classes:AuthenticatedTelephony
  • urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered
  • urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
  • urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI
  • urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken

Out of the box, OIF/IdP has the following mappings for the SAML 2.0 protocol:

  • Only urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport is defined
  • This Federation Authentication Method is mapped to:
    • LDAPScheme, marked as the default scheme used for authentication
    • FAAuthScheme
    • BasicScheme
    • BasicFAScheme
  • This mapping is defined in the saml20-sp-partner-profile SP Partner Profile which is the default OOTB SP Partner Profile for SAML 2.0

An example of an AuthnRequest message sent by an SP to an IdP with the SP requesting a specific Federation Authentication Method to be used to challenge the user would be:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://idp.com/oamfed/idp/samlv20" ID="id-8bWn-A9o4aoMl3Nhx1DuPOOjawc-" IssueInstant="2014-03-21T20:51:11Z" Version="2.0">
  <saml:Issuer ...>https://acme.com/sp</saml:Issuer>
  <samlp:NameIDPolicy AllowCreate="false" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
  <samlp:RequestedAuthnContext Comparison="minimum">
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

An example of an Assertion issued by an IdP would be:

<samlp:Response ...>
    <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
        <dsig:Signature>
            ...
        </dsig:Signature>
        <saml:Subject>
            <saml:NameID ...>[email protected]</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://acme.com/sp</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>

An administrator would be able to specify a mapping between a SAML 2.0 Federation Authentication Method and one or more OAM Authentication Schemes

SAML 1.1

The SAML 1.1 specifications define the following Federation Authentication Methods for SAML 1.1 flows:

  • urn:oasis:names:tc:SAML:1.0:am:unspecified
  • urn:oasis:names:tc:SAML:1.0:am:HardwareToken
  • urn:oasis:names:tc:SAML:1.0:am:password
  • urn:oasis:names:tc:SAML:1.0:am:X509-PKI
  • urn:ietf:rfc:2246
  • urn:oasis:names:tc:SAML:1.0:am:PGP
  • urn:oasis:names:tc:SAML:1.0:am:SPKI
  • urn:ietf:rfc:3075
  • urn:oasis:names:tc:SAML:1.0:am:XKMS
  • urn:ietf:rfc:1510
  • urn:ietf:rfc:2945

Out of the box, OIF/IdP has the following mappings for the SAML 1.1 protocol:

  • Only urn:oasis:names:tc:SAML:1.0:am:password is defined
  • This Federation Authentication Method is mapped to:
    • LDAPScheme, marked as the default scheme used for authentication
    • FAAuthScheme
    • BasicScheme
    • BasicFAScheme
  • This mapping is defined in the saml11-sp-partner-profile SP Partner Profile which is the default OOTB SP Partner Profile for SAML 1.1

An example of an Assertion issued by an IdP would be:

<samlp:Response ...>
    <samlp:Status>
        <samlp:StatusCode Value="samlp:Success"/>
    </samlp:Status>
    <saml:Assertion Issuer="https://idp.com/oam/fed" ...>
        <saml:Conditions ...>
            <saml:AudienceRestriction>
                <saml:Audience>https://acme.com/sp/ssov11</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthenticationInstant="2014-03-21T20:53:55Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
            <saml:Subject>
                <saml:NameID ...>[email protected]</saml:NameID>
                <saml:SubjectConfirmation>
                   <saml:ConfirmationMethod>
                       urn:oasis:names:tc:SAML:1.0:cm:bearer
                   </saml:ConfirmationMethod>
                </saml:SubjectConfirmation>
            </saml:Subject>
        </saml:AuthnStatement>
        <dsig:Signature>
            ...
        </dsig:Signature>
    </saml:Assertion>
</samlp:Response>

Note: SAML 1.1 does not define an AuthnRequest message.

An administrator would be able to specify a mapping between a SAML 1.1 Federation Authentication Method and one or more OAM Authentication Schemes

OpenID 2.0

The OpenID 2.0 PAPE specifications define the following Federation Authentication Methods for OpenID 2.0 flows:

  • http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
  • http://schemas.openid.net/pape/policies/2007/06/multi-factor
  • http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

Out of the box, OIF/IdP does not define any mappings for the OpenID 2.0 Federation Authentication Methods.

For OpenID 2.0, the configuration will involve mapping a list of OpenID 2.0 policies to a list of Authentication Schemes.

An example of an OpenID 2.0 Request message sent by an SP/RP to an IdP/OP would be:

https://idp.com/openid?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=checkid_setup&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.assoc_handle=id-6a5S6zhAKaRwQNUnjTKROREdAGSjWodG1el4xyz3&openid.return_to=https%3A%2F%2Facme.com%2Fopenid%3Frefid%3Did-9PKVXZmRxAeDYcgLqPm36ClzOMA-&openid.realm=https%3A%2F%2Facme.com%2Fopenid&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_request&openid.ax.type.attr0=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.if_available=attr0&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.max_auth_age=0

An example of an Open ID 2.0 SSO Response issued by an IdP/OP would be:

https://acme.com/openid?refid=id-9PKVXZmRxAeDYcgLqPm36ClzOMA-&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Fidp.com%2Fopenid&openid.claimed_id=https%3A%2F%2Fidp.com%2Fopenid%3Fid%3Did-38iCmmlAVEXPsFjnFVKArfn5RIiF75D5doorhEgqqPM%3D&openid.identity=https%3A%2F%2Fidp.com%2Fopenid%3Fid%3Did-38iCmmlAVEXPsFjnFVKArfn5RIiF75D5doorhEgqqPM%3D&openid.return_to=https%3A%2F%2Facme.com%2Fopenid%3Frefid%3Did-9PKVXZmRxAeDYcgLqPm36ClzOMA-&openid.response_nonce=2014-03-24T19%3A20%3A06Zid-YPa2kTNNFftZkgBb460jxJGblk2g--iNwPpDI7M1&openid.assoc_handle=id-6a5S6zhAKaRwQNUnjTKROREdAGSjWodG1el4xyz3&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_response&openid.ax.type.attr0=http%3A%2F%2Fsession%2Fcount&openid.ax.value.attr0=1&openid.ax.type.attr1=http%3A%2F%2Fopenid.net%2Fschema%2FnamePerson%2Ffriendly&openid.ax.value.attr1=My+name+is+Bobby+Smith&openid.ax.type.attr2=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.value.attr2=bob&openid.ax.type.attr3=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.value.attr3=bob%40oracle.com&openid.ax.type.attr4=http%3A%2F%2Fsession%2Fipaddress&openid.ax.value.attr4=10.145.120.253&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_time=2014-03-24T19%3A20%3A05Z&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fphishing-resistant&openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2Cassoc_handle%2Cns.ax%2Cax.mode%2Cax.type.attr0%2Cax.value.attr0%2Cax.type.attr1%2Cax.value.attr1%2Cax.type.attr2%2Cax.value.attr2%2Cax.type.attr3%2Cax.value.attr3%2Cax.type.attr4%2Cax.value.attr4%2Cns.pape%2Cpape.auth_time%2Cpape.auth_policies&openid.sig=mYMgbGYSs22l8e%2FDom9NRPw15u8%3D


In the next article, I will provide examples on how to configure OIF/IdP for the various protocols, to map OAM Authentication Schemes to Federation Authentication Methods.
Cheers,
Damien Carru

© Oracle Blogs or respective owner

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Related posts about /Oracle

Categories cloud

.NET ASP.NET iphone linux python Windows mysql android sql windows-7 html c ruby-on-rails css objective-c ubuntu networking sql-server wpf asp.net-mvc ruby database Xml apache AJAX osx security regex django Performance 12.04 windows-xp mac web-development iphone-sdk vb.net Silverlight apache2 flash server perl best-practices email installation eclipse visual-studio algorithm windows-server-2008 winforms wcf firefox bash dns /Oracle