X

Tips and HowTos for Single Sign-On & Federation Oracle Identity Management Integrations

Recent Posts

Identity Cloud Service & SAML

Identity Cloud Service or IDCS provides Identity Management capabilities hosted in the Cloud to Oracle customers, including: User & Group Management SAML SSO with SAML SPs and IdPs OpenID Connect SSO with SPs .... In today’s article, I will be going over the SAML features supported by IDCS 17.2.2 and later. SAML Support Protocol The following SAML 2.0 protocols and bindings are supported by IDCS: SAML 2.0 SSO Protocol Sending and receiving of the SAML AuthnRequest via HTTP-Redirect or HTTP-POST bindings Sending and receiving of the SAML Response containing the SAML Assertion via the HTTP-POST binding SAML 2.0 Logout Protocol Sending and receiving of the SAML LogoutRequest via HTTP-Redirect or HTTP-POST bindings Sending and receiving of the SAML LogoutResponse via HTTP-Redirect or HTTP-POST bindings SAML 2.0 Metadata The IDCS SAML Service can generate a SAML 2.0 Metadata document listing the services and certificates used for Federation SSO The IDCS SAML Service can also consume a SAML 2.0 Metadata during Federation trust establishment. Cryptography The IDCS SAML service supports the following cryptographic features: SHA-256 and SHA-1 as the signature hash algorithm The inclusion of the IDCS Signing Certificate in outgoing SAML messages, when the message is sent using the HTTP-POST binding When IDCS is acting as a SAML IdP during the SAML Assertion Generation: Either the SAML Response or the SAML Assertion will be signed The SAML Assertion can be encrypted using AES-128-CBC, AES-192-CBC, AES-256-CBC or 3DES-CBC When IDCS is acting as a SAML SP during the SAML Assertion Consumption: Either the SAML Response or the SAML Assertion must be signed SAML Assertion Generation As an IdP, IDCS supports the following when issuing a SAML 2.0 Assertion NameID Format urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos urn:oasis:names:tc:SAML:2.0:nameid-format:persistent urn:oasis:names:tc:SAML:2.0:nameid-format:transient Custom NameID format NameID Value Username or Primary Email user attribute stored in the Identity Store for any NameID format except urn:oasis:names:tc:SAML:2.0:nameid-format:transient For urn:oasis:names:tc:SAML:2.0:nameid-format:transient, a one-time random identifier SAML Attributes The following user attributes stored in the Identity Store Username Given Name Middle Name Family Name Primary Email Address Work Email Address Phone Numbers (home, mobile, work) Title Work Address attributes User Groups The SAML Attribute name can be set by the administrator The SAML Assertion will contain an attribute that will hold of the Identity Domain name: Name: oracle:cloud:identity:domain Value: the customer's identity domain name SAML Assertion Consumption As an SP, IDCS will validate the incoming SAML Assertion and map it to an IDCS user record. The service supports the following: NameID Format urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos urn:oasis:names:tc:SAML:2.0:nameid-format:persistent urn:oasis:names:tc:SAML:2.0:nameid-format:transient Custom NameID format Assertion Mapping Either based on the NameID contained in the Assertion that will be mapped to a user record attribute in the Identity Store Or based on a SAML Attribute contained in the Assertion that will be mapped to a user record attribute in the Identity Store The information from the SAML Assertion will be mapped to one of those user record attributes: Username Display Name Given Name Middle Name Family Name Primary Email Address Any other email addresses (home, work, other, recovery) Endpoints The services implementing the SAML 2.0 protocol are published at: /fed/v1/idp/sso for the IdP Single Sign On Service, where the SP redirects the user with the SAML AuthnRequest to the IdP /fed/v1/idp/slo for the IdP Single Logout Service, where the SP redirects the user with the SAML LogoutRequest or LogoutResponse to the IdP /fed/v1/sp/sso for the SP Assertion Consumer Service, where the IdP redirects the user with the SAML Response containing the SAML Assertion to the SP /fed/v1/sp/slo for the SP Single Logout Service, where the IdP redirects the user with the SAML LogoutRequest or LogoutResponse to the SP /fed/v1/metadata for the SAML 2.0 Metadata The SAML service also provides two endpoints to initiate a Federation SSO operation, ignoring whether or not the user is already authenticated at the target SP domain. As a consequence, these flows should not be primarily used, and instead the user should be sent to the target SSO service which will determine whether or not an authentication involving Federation SSO is required. Both SAML services (IdP or SP) support starting a Federation SSO: IdP Initiated SSO: Endpoint: /fed/v1/idp/initiatesso Query Parameters (one of providerid, partnerguid or partnername is required; returnurl is optional) providerid: the SP ProviderID partnername: the name of the SP as registered in IDCS partnerguid: the unique GUID of the SP as registered in IDCS returnurl: the location where the user should be redirected after the Federation SSO is completed SP Initiated SSO: Endpoint: /fed/v1/sp/initiatesso Query Parameters (one of providerid, partnerguid or partnername is required; returnurl is optional) providerid: the IdP ProviderID partnername: the name of the IdP as registered in IDCS partnerguid: the unique GUID of the IdP as registered in IDCS returnurl: the location where the user should be redirected after the Federation SSO is completed Cheers, Damien Carru

Identity Cloud Service or IDCS provides Identity Management capabilities hosted in the Cloud to Oracle customers, including: User & Group Management SAML SSO with SAML SPs and IdPs OpenID Connect SSO...

SP vs. IdP Initiated SSO

In today's article, I will discuss about the concepts of SP and IdP Initiated SSO between two Federation deployments, and what the differences between those two flows are. I will also explain the concept of a user state or a return URL shared between the IdP and the SP during the Federation SSO, which is called: RelayState for SAML 2.0 TARGET for SAML 1.1 wctx for WS-Fed 1.1 openid.return_to for OpenID 2.0 (the return SSO URL can contain a query parameter representing the user state at the SP) In this article, I will showcase examples using the SAML 2.0 protocol, though the same would apply for the other protocols. Enjoy the reading! Federation SSO Flows Topology A typical Federation deployment is made of the following entities: A security domain for the IdP Server, where the user has an account and where authentication will occur A security domain for the SP server with An SP Federation Server An SSO server (sometimes, the SSO Server and the SP Federation Server are the same entity) SSO Web Agents integrated with the SSO Server, protecting resources and ensuring that the user is authenticated and authorized to access a resource. Failure to do so might result in an authentication flow or an authorization failure Resources or Web Applications SP Initiated SSO   An SP Initiated SSO flow is a Federation SSO operation that was started from the SP Security Domain, by the SP Federation server creating a Federation Authentication Request and redirecting the user to the IdP with the message and some short string representing the operation state: The Federation Authentication Request varies depending on the protocol used: SAML 2.0: AuthnRequest SAML 1.1: a URL with a parameter representing the SP WS-Fed: a URL with a wtrealm parameter representing the SP and other optional parameters OpenID 2.0: OpenID 2.0 Request The operation state (what the user was doing before the Federation SSO operation started) is conveyed in the message sent to the IdP with the user, not as the whole state, but instead as a pointer to the state in the SP Server's runtime storage. This information is conveyed differently depending on the protocol: SAML 2.0: RelayState parameter SAML 1.1: TARGET parameter WS-Fed: wctx parameter OpenID 2.0: openid.return_to parameter which is an SP URL where the user will be redirected after authentication at the IdP, which is generated at runtime by the SP, and as such can contain a query parameter referencing an operational state Note about the operational state: generally speaking, the state shared in the message should not be too long, as it might break the redirect flows with the redirect URL length exceeding the maximum length that browsers can handle for URLs. As such it is always preferable during SP Initiated SSO to have the SP Store the operational state in memory/DB storage at the SP Send as the RelayState/TARGET/wctx a pointer to the operational state There are two ways for an SP Initiated SSO flow to be triggered: The user requests access to a resource, which will start a Federation SSO flow. Once the Federation SSO operation is performed, the user will be redirected back to the resource requested in the first place. Or the user accesses directly a service on the SP server to specifically start a Federation SSO flow with a remote IdP. In this case, the user typically provides the URL where the user should be redirected after the Federation SSO operation is performed Accessing a Resource This is the most common flow for Federation SSO operations, where the user attempts to access a protected resource, and the SSO system at runtime determines that the user needs to be authenticated via Federation SSO. The use cases where this flow is used can be: User clicks on a link on any page referencing the protected resource User clicks on a link on a portal page referencing the protected resource User has a bookmark for the protected resource The flow would involve the following steps: User's browser request access to a protected resource The SSO Web Agent intercepts the call, determines that the user needs to be authenticated and issues a redirect back to the user's browser The user's browser accesses the SSO server, being redirected by the SSO Web Agent The SSO Server determines that the user should be authenticated via Federation SSO, selects an IdP, creates a SAML 2.0 AuthnRequest message, saves the operational state in the SSO server store and redirects the user's browser to the IdP with the SAML message and a string referencing the operational state at the SP The user's browser accesses the IdP SAML 2.0 service with the AuthnRequest message. Once the IdP receives the SAML 2.0 AuthnRequest message, the server will determine if the user needs to be challenged (not authenticated yet, session timed out...). After the possible identification of the user, the Federation SSO flow will resume: The IdP creates an SSO Response with a SAML 2.0 Assertion containing user information as well as authentication data, and redirects the user's browser to the SP with the message and the RelayState parameter The user's browser presents the SSO response to the SP server The SP validates the SAML 2.0 Assertion and creates an SSO session for the user. The SSO server will then redirect the user's browser back to the resource originally requested The user's browser requests access to the resource. This time the SSO Web Agent grants access to the resource The Web Application returns a response to the user's browser As mentioned previously, this flow is the most commonly used, as the Federation SSO is only triggered by the SSO server at runtime, without any other components in the SP Security Domain needing to be aware of Federation. Invoking a Federation SP Service This flow is not widely used, as it implies that the Federation SSO will be started at the SP by accessing a service at the SP server, and by disregarding any existing valid session the user could already have. As such this should be avoided as it incurs a performance impact on: The servers as Federation SSO is expensive (XML for some protocols, digital signatures to protect the messages, communications between servers) The user's experience as the browser will be redirected across different domains resulting in a delay before the user can get access to the targeted protected resource. The use cases where this flow is used can be: User clicks on a link on any page referencing the protected resource (unusual) User clicks on a link on a portal page referencing the protected resource The use cases where this flow is used would involve the following steps: The user's browser accesses the SP to start a Federation SSO flow by optionally specifying The URL where the user's browser should be redirected after the Federation SSO is complete The IdP to be used The SSO Server selects an IdP if not provided and selects the default return URL if not provided, creates a SAML 2.0 AuthnRequest message, saves the operational state in the SSO server store and redirects the user's browser to the IdP with the SAML message and a string referencing the operational state at the SP The user's browser accesses the IdP SAML 2.0 service with the AuthnRequest message. Once the IdP receives the SAML 2.0 AuthnRequest message, the server will determine if the user needs to be challenged (not authenticated yet, session timed out...). After the possible identification of the user, the Federation SSO flow will resume: The IdP creates an SSO Response with a SAML 2.0 Assertion containing user information as well as authentication data, and redirects the user's browser to the SP with the message and the RelayState parameter The user's browser presents the SSO response to the SP server The SP validates the SAML 2.0 Assertion and creates an SSO session for the user. The SSO server will then redirect the user's browser back to the resource originally requested The user's browser requests access to the resource. This time the SSO Web Agent grants access to the resource The Web Application returns a response to the user's browser This flow should be rarely used, as the Federation SSO is triggered statically, even if the user already has a valid SSO session. Also, it implies that some components in the SP Security Domain to be aware of the SP service. IdP Initiated SSO   An IdP Initiated SSO flow is a Federation SSO operation that was started from the IdP Security Domain, by the IdP Federation server creating a Federation SSO Response and redirecting the user to the SP with the response message and an optional operational state: The Federation SSO Response varies depending on the protocol used: SAML 2.0: SAMLResponse with Assertion SAML 1.1: Response with Assertion WS-Fed: Response with Assertion OpenID 2.0: OpenID 2.0 Response The optional operation state in this flow will convey the URL where the user should be redirected after the Federation SSO is complete at the SP. If missing, the SP will need to determine where the user should be redirected. This information is conveyed differently depending on the protocol: SAML 2.0: RelayState parameter SAML 1.1: TARGET parameter WS-Fed: wctx parameter OpenID 2.0: this protocol does not support IdP Initiated SSO flow. As noted in the previous section, the state shared in the message should not be too long, as it might break the redirect flows with the redirect URL length exceeding the maximum length that browsers can handle for URLs. This flow is commonly used when IdP users need to access resources hosted by an SP, but it is not the best approach for Federation SSO, as it disregards any existing valid session at the SP the user could already have. As such this should be avoided as it incurs a performance impact on: The servers as Federation SSO is expensive (XML for some protocols, digital signatures to protect the messages, communications between servers) The user's experience as the browser will be redirected across different domains resulting in a delay before the user can get access to the targeted protected resource. The use cases where this flow is used can be: User clicks on a link on an IdP portal page referencing the protected resource at the SP. The use cases where this flow is used would involve the following steps: The user's browser accesses the IdP to start a Federation SSO flow by specifying The SP to be used Optionally the URL where the user's browser should be redirected after the Federation SSO is complete After having identified the user, the IdP creates an SSO Response with a SAML 2.0 Assertion containing user information as well as authentication data, and redirects the user's browser to the SP with the message and the RelayState parameter The user's browser presents the SSO response to the SP server The SP validates the SAML 2.0 Assertion and creates an SSO session for the user. The SSO server will then redirect the user's browser back to the resource originally requested The user's browser requests access to the resource. This time the SSO Web Agent grants access to the resource The Web Application returns a response to the user's browser Conclusion   As seen in the various flows, the best approach in a Federation deployment is for the Federation SSO to be triggered by the SSO server, at runtime, when it is deemed required by the SSO server. The other cases have a static approach and will always exercise a Federation SSO flow, even if it is not required (if the user has already a valid session for example), and performing unnecessary Federation operations will impact: The servers' performances (CPU, LDAP/RDBMS interactions...) The user's response time, based on the time it takes to perform a Federation SSO operation with the redirects involved. Cheers, Damien Carru  

In today's article, I will discuss about the concepts of SP and IdP Initiated SSO between two Federation deployments, and what the differences between those two flows are. I will also explain the...

Integrating Google IdP with OIF SP

Google Apps recently introduced a new SAML 2.0 feature, where Google can now act as an Identity Provider with remote SAML 2.0 Service Providers. This allows using Google as: The authentication authority for end users The server that will provide true SSO capabilities as the user authentication state is propagated from the Google IdP to remote domains In this article, I will describe step by step how to integrate Google IdP with OIF as an SP via the SAML 2.0 SSO protocol. Enjoy the reading! User Mapping Users in Google Apps are uniquely identified by their email addresses which was set when those users were created. During a SAML 2.0 SSO flow, the Google IdP will provide the user's email address to the remote SP: In the SAML 2.0 NameID field With the NameID value set to the user's primary email address In the next steps, I will show how to determine the user's primary email address in Google Apps. To view a user account in Google Apps, perform the following steps: Launch a browser Go to http://www.google.com/a Click Sign In Perform the following steps: In the domain field, enter the name of your domain (in this example, www.acme.com) Select Admin Console Click Go Perform the following steps: In the Dashboard, click on Users Perform the following steps: Select a user to view The next screen will show details about the user. The email address is displayed underneath the user's identity. In this example, the Google IdP will send alice@acme.com to the remote SP during the SAML 2.0 SSO operation: Google IdP Configuration Collecting OIF Information The following information will need to be provided into the Google IdP SSO Admin console: SAML 2.0 SSO SP endpoint ProviderID In this earlier article, I listed the endpoints published by OIF. The SAML 2.0 SSO IdP endpoint and the SAML 2.0 logout endpoint would be http(s)://oam-public-hostname:oam-public-port/oamfed/idp/samlv20, with oam-public-hostname and oam-public-port being the values of the public endpoint, where the user will access the OAM/OIF application (load balancer, HTTP reverse proxy...). If you are unsure about the oam-public-hostname and oam-public-port, you can: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Settings -> Access Manager The oam-public-hostname is the OAM Server Host, the oam-public-port is the OAM Server Port and the protocol (http or https) is listed in OAM Server Protocol. In the same article, I also explained how to determine the ProviderID used by OIF: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Settings -> Federation Write down the ProviderID Configuring the Google IdP To configure Google as an IdP, perform the following steps: Launch a browser Go to https://www.google.com/enterprise/apps/business/ Authenticate and go to the Admin Dashboard Click on Apps Perform the following steps: Click on SAML Apps Perform the following steps: Click on Add a service/App to your domain Perform the following steps: Click on SETUP MY CUSTOM APP Perform the following steps: In the section Option 2, click the Download button to download the Google IdP SAML 2.0 Metadata file on your local machine Once done click Next Perform the following steps: Enter an Application Name Optionally upload a logo Once done click Next Perform the following steps: Enter the ACS (Assertion Consumer Service URL) http(s)://oam-public-hostname:oam-public-port/oam/server/fed/sp/sso Based on the OIF information collected earlier replace http(s) by the OAM public endpoint protocol and the oam-public-hostname and oam-public-port by their values Enter the ProviderID collected earlier in the Entity ID field Leave Primary Email as the NameID, as we will use the email contained in the NameID to map the user in OAM/SP Optionally enter a Start URL for Google IdP Initiated SSO operations, where the user will click on the SAML Application partner at Google to be redirected to the Application at OAM: this would be the protected application URL, or unsolicited Relay State. Click Next Perform the following steps: In this section, you can add attributes that will be sent by the Google IdP. To add an attribute: Click ADD NEW MAPPING Enter the name as it will appear in the SAML Assertion in the first field Select the category of the User attribute from the Google LDAP you wish to send Select the attribute you wish to send Once done click FINISH If the setup was successful, a success message will be displayed: To enable the SP Application, you will need to turn it on: Click on the Menu for the SAML application Click on ON for Everyone Perform the following steps: Confirm by clicking TURN ON FOR EVERYONE OIF Setup To add Google as an IdP partner in OIF, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Click on Federation Navigate to Federation -> Service Provider Management Click on the “Create Identity Provider Partner” button In the Create screen: Enter a name for the Google IdP Check whether or not this partner should be used as the IdP by default when starting a Federation SSO operation, if no IdP partner is specified. (in this example we will set it as the default IdP) Select SAML 2.0 as the Protocol Click Load Metadata and upload the SAML 2.0 Metadata file for the Google IdP Assertion Mapping section: Optionally set the OAM Identity Store that should be used (note: in the example, I left the field blank to use the default OAM Identity Store) Optionally set the user search base DN (note: in the example, I left the field blank to use the user search base DN configured in the Identity Store) Select how the mapping will occur (note: in the example, I am mapping the Assertion via the NameID to the LDAP mail attribute) Click Save Test To test: Either protect a resource with WebGate and a FederationScheme with ADFS IdP being the Default SSO Identity Provider for OIF Or use the OIF Test SP application and select Google as the IdP To test using the Test SP: Ensure that the Test SP Application has been enabled (see my previous article) Navigate to http(s)://oam-public-hostname:oam-public-port/oamfed/user/testspsso Select the Google IdP Click Start SSO At the Google IdP, enter the user's email address Enter the user's password Once entered, the Google IdP will authenticate you and redirect you to the OAM SAML SP that will show the result of the Federation SSO. In my next article, I will cover the SP Initiated SSO flows vs IdP Initiated SSO flows.Cheers,Damien Carru

Google Apps recently introduced a new SAML 2.0 feature, where Google can now act as an Identity Provider with remote SAML 2.0 Service Providers. This allows using Google as: The authentication authority...

Transient Federations

In my previous article I discussed how to use a Federation Data Store to save/retrieve: SAML 2.0 Persistent NameIDs OpenID 2.0 NameIDs As part of that article, I mentioned the SAML 2.0 Transient NameID format. In today's entry, I will cover how can OIF/OAM be configured to use SAML 2.0 Transient NameID format when acting as an IdP or as an SP. Transient NameID Format The SAML 2.0 specifications define the Transient NameID format as a NameID whose value will be a random identifier, unique for this Federation SSO operation and used only one time. This is typically used in cases where the SP does not care to know who the user is, but only wishes to know that the user is a valid user at the IdP that was successfully authenticated. If the user wants to know more information about the user via SAML Attributes contained in the SAML Assertion, then it does not really make sense to use the Transient NameID format. An example of an Assertion issued by an IdP with an Transient NameID 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 NameQualifier="https://idp.com/oam/fed" SPNameQualifier="https://acme.com/sp" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">id-U-2ajxWgNtPyLEv4NVz0Vsvuf7w-</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> A subsequent Federation SSO operation for the same user with the same IdP and SP would result in a new transient NameID value being created. Configuring OIF / IdP The OIF server acting as an IdP supports the Transient NameID format, where the IdP will issue an Assertion with a random transient value. This value will be randomly generated every time a Federation SSO occurs, even if the same user performs the Federation SSO operation once again with the same SP Partner. To configure OIF/IdP to use Transient as the NameID format for a specific SP partner, perform the following steps: 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 setSPSAMLPartnerNameID WLST command:setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false") partnerName will be the SP Partner Name nameIDFormat will be set to orafed-transient nameIDValue will be left empty An example would be:setSPSAMLPartnerNameID("acmeSP", "orafed-transient") Exit the WLST environment:exit() After executing this WLST command, OIF/IdP would issue an Assertion with a Transient NameID format. Configuring OIF/SP Mapping the Incoming Assertion In OAM/OIF acting as an SP, the incoming Assertion must be mapped to an LDAP user account, as OAM requires an LDAP user in order to create an OAM session. When mapping an incoming Assertion with a Transient NameID format, two choices are available: Mapping the Assertion via SAML User Attributes (for example one of the SAML Attribute contains the userID or the user's email address) Mapping the Assertion to a static LDAP account for that IdP (for example, mapping the Assertions coming from AcmeIdP to a user account called user-acmeIDP) Mapping via SAML Attributes In this example, I will map an incoming SAML Assertion via a SAML Attribute. The Assertion contains issued by acmeIdP contains an attribute called username which I will use to map the Assertion to a local user record. Perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Federation -> Service Provider Administration Create a new IdP Partner or edit an existing one In the Mapping section Select "Map assertion attribute to User ID Store attribute" In this example, since I want to use the SAML Attribute called username, I will enter username as the Assertion Attribute In this example I will attempt to map the username SAML Attribute to the LDAP uid attribute Save In this example, the Assertion issued by the IdP would look like: <samlp:Response ...>    <saml:Issuer ...>https://acme.com/idp</saml:Issuer>    <samlp:Status>        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>    </samlp:Status>    <saml:Assertion ...>        <saml:Issuer ...>https://acme.com/idp</saml:Issuer>        <dsig:Signature>            ...        </dsig:Signature>        <saml:Subject> <saml:NameID NameQualifier="https://acme.com/idp" SPNameQualifier="https://sso.com/oam/fed" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">id-ev7P-H33gv6DQpGCQuwIXP-EEGk-</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://sso.com/oam/fed</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:AttributeStatement ...> <saml:Attribute Name="username" ...>                <saml:AttributeValue ...>alice</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="emailAddress" ...>                <saml:AttributeValue ...>alice@oracle.com</saml:AttributeValue>            </saml:Attribute>        </saml:AttributeStatement>    </saml:Assertion></samlp:Response> And using the Test SP SSO application, the result would be: Mapping via a Static LDAP Account It is possible to configure OIF/SP to map all incoming Assertions from a specific IdP Partner to a static LDAP account: every incoming users with an assertion issued by that IdP partner would then be mapped to the same LDAP account. Since all the OAM sessions for different users will be created for the same LDAP account, there might be a problem where OAM raises an error due to the maximum number of sessions for the same user being reached: indeed, OAM ensures at runtime that a specific LDAP user account cannot have more than the maximum number of sessions set by the OAM administrator. Currently, when configuring OIF/SP to map all incoming Assertions from a specific IdP Partner to a static LDAP account, there is no capability to bypass the OAM maximum number of session per user feature. The OAM administrator will have to raise the limit consequently. To configure the IdP Partner entry so that OIF/SP will map all incoming Assertions to the same static LDAP account, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Federation -> Service Provider Administration Create a new IdP Partner or edit an existing one In the Mapping section Select "Map assertion to user record using LDAP query" In this example, I will map to the LDAP user record which has uid=userForAcmeIdP. As such, I will enter the LDAP query: (uid=userForAcmeIdP) Save To configure Maximum Number of Sessions per User in , perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Common Settings Set the Maximum Number of Sessions per User setting, according to your requirements Apply I created a user called userForAcmeIdP in the LDAP directory, based on the LDIF data: version: 1DN: cn=userForAcmeIdP,ou=users,dc=us,dc=oracle,dc=comobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topcn: userForAcmeIdPgivenName: UserForAcmeIdPmail: userForAcmeIdP@oracle.comsn: UserForAcmeIdPuid: userForAcmeIdP Using the Test SP SSO application to perform a Federation SSO operation, the result would be: In my next article, I will cover how to integrate Google IdP with OIF SP.Cheers,Damien Carru

In my previous article I discussed how to use a Federation Data Store to save/retrieve: SAML 2.0 Persistent NameIDs OpenID 2.0 NameIDs As part of that article, I mentioned the SAML 2.0 Transient NameID...

Persistent Federation Data Store

When performing Federation SSO operations, the user will be referenced in the SSO message via a unique identifier that will then be used by the SP to map the incoming SSO response to a local user.Sometimes the unique identifier is an attribute part of the existing LDAP user record, such as the email address or the username, while other times, the identifier only exists for the Federation SSO operation between the SP and IdP for a specific user. In the latter case, the identifier and the user it is attached to need to be stored as account linking information in a Federation Data Store.In this article, I will show how to configure OIF to use an RDBMS as the Federation Data Store.Important note: a persistent Federation Data Store is only required for cases where the identifiers used in the SSO responses (persistent NameID in SAML 2.0 for example) are used. It is best not to use a persistent Federation Data Store when not needed.Identifiers in Federation MessagesEach Federation protocol uses an identifier to reference the user in the SSO message, though there are variations and differencesSAML 2.0SAML 2.0 uses three kinds of identifiers:User attributes:These identifiers are user attributes that are typically know by both SP and IdP and stored in the LDAP user accountSAML 2.0 defines the following formats, though in OIF you can use any formats:urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifiedurn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressurn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectNameurn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedNameurn:oasis:names:tc:SAML:2.0:nameid-format:KerberosTypically, using those identifiers does not require a persistent Federation Store, as the values are stored in the LDAP user entryOne time identifierThis is a specific identifier defined in the SAML 2.0 specifications where the IdP creates a random and onetime identifier when creating the assertion. This means that the next time the same user does a Federation SSO operation with the same SP, another random and one-time-use identifier will be usedThe name of that identifier is transient and defined by urn:oasis:names:tc:SAML:2.0:nameid-format:transientSince this is a onetime identifier, this will never be stored in a persistent Federation StoreRandom persistent identifierThis identifier is a random string, unique to the triplet IdP/SP/UserThis identifier will always be the same one sent by the IdP in a SAML 2.0 Assertion for that SP and for that userIt needs to be stored in a persistent Federation Store at the IdP, but it is optional for the SP, if the SP is mapping the Assertion to an LDAP user record using SAML Attributes contained in the SAML AssertionNote: with OIF as an IdP, it is possible to use the Persistent NameID format and to populate the value based on expressions, the same way other NameID formats are used. If the NameID value field is filled for the Persistent NameID format in the SP Partner screen, then OIF/IdP will use that expression to set the NameID value.An example of an Assertion issued by an IdP with an Email Address NameID 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 Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">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://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 example of an Assertion issued by an IdP with a persistent NameID 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 NameQualifier="https://idp.com/oam/fed" SPNameQualifier="https://acme.com/sp" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">id-424129fa23490ded8eab00cc</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>SAML 1.1SAML 1.1 only uses user attributes as NameIDs:These identifiers are user attributes that are typically know by both SP and IdP and stored in the LDAP user accountSAML 1.1 defines the following formats, though in OIF you can use any formats:urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifiedurn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressurn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectNameurn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedNameThere is no need to use a persistent Federation Data Store for SAML 1.1An example of an Assertion issued by an IdP with an Email Address NameID 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:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">bob@oracle.com</saml:NameIdentifier>                <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>OpenID 2.0OpenID 2.0 only uses random persistent identifiers as NameIDs:This identifier is a random string, unique to the triplet IdP/SP/UserThis identifier will always be the same one sent by the IdP in a OpenID 2.0 SSO Response for that SP and for that userIt needs to be stored in a persistent Federation Store at the IdP, but it is optional for the SP, if the SP is mapping the SSO Response to an LDAP user record using OpenID Attributes contained in the OpenID SSO ResponseAn example of an OpenID SSO Response issued by an IdP 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%3DFederation Data StoreAs seen earlier, a Federation Data Store is required for the following use cases:IdP SAML 2.0 when using Persistent NameID formatOpenID 2.0SPSAML 2.0 when using Persistent NameID format and not mapping the user via SAML AttributesOpenID 2.0 and not mapping the user via OpenID SSO AttributesA Federation Data Store is used to store Account Linking Information which is made of:The user IDThe opaque identifier usedThe ProviderID of the remote partner for which the opaque identifier was createdIdPAs an IdP, the Federation Data Store is required in order to send the same unique opaque identifier that was randomly generated the first time the user performed a Federation SSO operation between the IdP and the SP.OIF is capable of sending a unique opaque identifier for SAML 2.0 Persistent NameID format and OpenID 2.0 which will be the SHA-256 hash of the:Canonical User ID (OAM ID Store Name + User's DN + UserID)SP ProviderIDThis feature allows the use of SAML 2.0 Persistent NameID format and OpenID 2.0 without having to enable a Federation Data Store (see later on how to configure OIF)SPAs an SP, the Federation Data Store is required if the incoming SSO response is not mapped via SSO Response/user attributes. In this case, the Account Linking Information needs to be present in the Federation Data Store in order for the SP to be able to successfully complete the operation. If the Account Linking Information does not exist, the SP will need to challenge and authenticate locally the user to determine its identity and create an Account Linking Information in the Federation Data Store (User + Opaque Identifier + IdP ProviderID).The flow at the SP would then be:IdP redirects user to SP with SSO response and opaque identifierSP attempts to locate the Account Linking Information entry in the Federation Data Store by performing a query based on the opaque identifier and the IdP's ProviderIDIf the query returns an Account Linking Information entry, the SP will extract the user ID from the entry and create a session for that userIf the query does not return an Account Linking Information entryThe SP will initiate a local login operation to authenticate the user Once the user is locally authenticated, the SP will create an Account Linking Information entry with    UserIDOpaque IdentifierIdP's ProviderIDConfiguring OIF to use a Federation Data StoreOut of the box, OIF is not configured to use a persistent Federation Data Store. So an error will be thrown ifOpenID 2.0 SSO is used SAML 2.0 Persistent NameID format not based on expressions (ie: the NameID value field in the SP Partner screen is empty) is usedNote: as mentioned earlier, OIF/IdP can be configured to populate the OpenID 2.0 and SAML 2.0 Persistent NameID with an opaque value based on the SHA-256 hash of the userID and SP's ProviderID, thus not requiring a Federation Data Store. More on this in the next section.RDBMSThe only supported Federation Data Store is an RDBMS, where the OAM schema exists, and the RDBMS needs to be defined as a JDBC datasource in the WLS server where OAM is runningEither use the jdbc/oamds JDBC datasource created during installation and referencing the OAM database used to store policy and session dataOr Install a new DB, create the OAM schema via RCUDefine a new JDBC datasource in WLS for the WLS managed servers where OAM is runningThe ORAFEDPROVIDERFED database table will contain the Account Linking Information entries:idpProvidedNameIDValue is the identifier valueproviderID is the ProviderID of the remote partneruserID is the canonical User ID (OAM ID Store Name + User's DN + UserID)federationType is the type of Federation1: OIF acts as an IdP and the remote partner is an SP3: OIF acts as an SP  and the remote partner is an IdPidpProvidedNameIDVersionString is the protocol version (SAML2.0 or OpenID2.0)userDescription is the userIDfedID is a unique identifier for this Account Linking Information entryNote: only OpenID 2.0 and SAML 2.0 Persistent NameID values will be stored in the Federation Data Store ConfigurationTo configure OIF to use a Federation Data Store, perform the following steps:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setFederationStore WLST command:setFederationStore(enable, jndiname="jdbc/oamds")To enable the Federation Data StoreSet enable to trueSet the optional jndiname parameter referencing the JDBC Datasource to use. If missing, the OAM JDBC Datasource will be usedAn example would be:setFederationStore("true")To disable the Federation Data Store:Set enable to trueAn example would be:setFederationStore("false")Exit the WLST environment:exit()Testing with OIF as an IdPIn this test, OIF will act as an IdP with a SAML 2.0 SP partner.To configure OIF/IdP to generate random persistent identifiers that will be stored in the Federation Data Store instead of using LDAP user attributes to populate the NameID value, perform the following steps:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setSPSAMLPartnerNameID WLST command:setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false")partnerName will be the SP Partner NamenameIDFormat will be set to orafed-persistentnameIDValue will be left empty. If not empty, then OIF/IdP will use the expression to populate the NameID value instead of generating a random persistent identifierAn example would be:setSPSAMLPartnerNameID("acmeSP", "orafed-persistent")Exit the WLST environment:exit()Executing the following SQL query in an empty ORAFEDPROVIDERFED table would not return any data:SQL> select idpProvidedNameIDValue, providerID, userID, federationType, idpProvidedNameIDVersionString, userDescription, fedID from ORAFEDPROVIDERFED;IDPPROVIDE PROVIDERID    USERID        FEDERATIONTYPE IDPPROVID USERDESC FEDID---------- ------------- ------------- -------------- --------- -------- ----------After performing Federation SSO with the remote partner SP, executing the query once again would show the new entry:SQL> select idpProvidedNameIDValue, providerID, userID, federationType, idpProvidedNameIDVersionString, userDescription, fedID from ORAFEDPROVIDERFED;IDPPROVIDE PROVIDERID    USERID        FEDERATIONTYPE IDPPROVID USERDESC FEDID---------- ------------- ------------- -------------- --------- -------- ----------id-s-l3991 http://acme.c oud-e2e:USER:              1 SAML2.0   alice    id-KKqR2ClUt7JEyggvf om/sp         cn=alice,ou=u                                   GnffAGhRLAIoPavO7Huj               sers,dc=us,dc                                   MzXZMx3UGj6H0UvFvEec               =oracle,dc=co                                   cMSQge9NhhWwq                      m:alice                                         NmeTesting with OIF as an SPIn this test, OIF will act as an SP with a SAML 2.0 IdP partner.To configure OIF/SP to use the Federation Data Store when mapping the incoming SAML 2.0/OpenID 2.0 SSO Response, perform the following steps:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setPartnerIDStoreAndBaseDN WLST command:setPartnerIDStoreAndBaseDN(partnerName, partnerType, storeName="", searchBaseDN="", delete="false")partnerName will be the IdP Partner NamepartnerType will be set to idpstoreName will be set to FederationStoresearchBaseDN and delete will not be setAn example would be:setPartnerIDStoreAndBaseDN("acmeIdP", "idp", "FederationStore")Exit the WLST environment:exit()Important: when OIF/SP performs a Federation SSO with an IdP partner using the SAML 2.0 Persistent NameID or OpenID 2.0 with the Federation Data Store, if the account linking information for the user and that IdP does not exist yet, OIF/SP will need to challenge and authenticate locally the user to be able to create that account linking information entry. The subsequent times, that user won't be challenged anymore since the account linking information entry will already exists.Executing the following SQL query in an empty ORAFEDPROVIDERFED table would not return any data:SQL> select idpProvidedNameIDValue, providerID, userID, federationType, idpProvidedNameIDVersionString, userDescription, fedID from ORAFEDPROVIDERFED;IDPPROVIDE PROVIDERID    USERID        FEDERATIONTYPE IDPPROVID USERDESC FEDID---------- ------------- ------------- -------------- --------- -------- ----------After performing Federation SSO with the remote partner IdP and after the user authenticates locally in order to be able to create the account linking information entry, executing the query once again would show the new entry:SQL> select idpProvidedNameIDValue, providerID, userID, federationType, idpProvidedNameIDVersionString, userDescription, fedID from ORAFEDPROVIDERFED;IDPPROVIDE PROVIDERID    USERID        FEDERATIONTYPE IDPPROVID USERDESC FEDID---------- ------------- ------------- -------------- --------- -------- ----------id-2eCUlO4 http://acme.c oud-e2e:USER:              3 SAML2.0   alice    id-VVSIks6gekO2rgZfe om/idp        cn=alice,ou=u                                   hzG2szNPyIYoZkof8YUM               sers,dc=us,dc                                   T5ccRf8dzy-                        =oracle,dc=co                                   NL0DZjDbGg                         m:alice                                         c-0Configuring OIF/IdP to use a Hash as NameIDIn case OIF acts as an IdP using SAML 2.0 Persistent NameID and/or OpenID 2.0 based on opaque identifiers and not LDAP user attributes, the server can be configured to populate the NameID based on the SHA-256 hash of the following data:Canonical User ID (OAM ID Store Name + User's DN + UserID)SP ProviderIDProtocol version usedTo configure OIF/IdP to use SHA-256 hash of the above data to populate the NameID, perform the following steps:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setSPSAMLPartnerNameID WLST command:setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false")partnerName will be the SP Partner NamenameIDFormat will be set to orafed-persistentnameIDValue will be left empty. If not empty, then OIF/IdP will use the expression to populate the NameID value instead of generating a random persistent identifiernameIDValueComputed will be set to trueAn example would be:setSPSAMLPartnerNameID("acmeSP", "orafed-persistent", nameIDValueComputed="true")Exit the WLST environment:exit()That way, OIF/IdP is not required to be configured to use a Federation Data Store (no need to execute setFederationStore("true") to enable DB as the Federation Data Store), in order to perform Federation SSO with:SAML 2.0 with opaque Persistent NameIDOpenID 2.0In my next article, I discuss about transient federations, that is SAML 2.0 SSO operations with the transient NameID format.Cheers,Damien Carru

When performing Federation SSO operations, the user will be referenced in the SSO message via a unique identifier that will then be used by the SP to map the incoming SSO response to a local user. Somet...

SAML 2.0 Setup: Metadata vs No-Metadata

This article will cover the benefits of using SAML 2.0 Metadata when establishing trust between two SAML 2.0 Federation servers, as opposed to provide and enter information manually by typing/copying/pasting URLs, certificates.Establishing TrustTrust establishment in the context of SAML 2.0 Web SSO is the act of configuring a SAML 2.0 Identity Provider and a SAML 2.0 Service Provider so that they can perform Federation SSO operations.Practically, this involves:Creating a partner entry at the SAML 2.0 Identity Provider that will represent the remote Service Provider with the following informationThe SP's EntityID or ProviderID which is the unique identifier referencing the SPThe Assertion Consumer Service URL(s) where the IdP will redirect the user with the SAML AssertionThere can be severalEach one might have a different URL and a different binding (for example urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST or urn:oasis:names:tc:SAML:2.0:bindings:PAOS)The Logout Service URLs where the IdP will redirect the user during the SAML 2.0 Logout exchangeThere can be severalEach one might have a different binding (for example urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST)Each Service might have different URLs to receive a LogoutRequest message and a LogoutResponse messageThe X.509 certificate(s) corresponding to the private key used by the SP to sign outgoing SAML 2.0 messages, such as the AuthnRequest, LogoutRequest/LogoutResponse or ArtifactResolve messagesThe X.509 certificate(s) corresponding to the private key used by the SP to decrypt incoming SAML 2.0 messages encrypted by remote IdPs with the certificate(s), such as the Assertion/NameID/Attribute elements inside an SSO ResponseCreating a partner entry at the SAML 2.0 Service Provider that will represent the remote Identity Provider with the following informationThe IdP's EntityID or ProviderID which is the unique identifier referencing the IdPThe Single Sign On Service URL(s) where the SP will redirect the user with the SAML AuthnRequestThere can be severalEach one might have a different URL and a different binding (for example urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST or urn:oasis:names:tc:SAML:2.0:bindings:SOAP)The Logout Service URLs where the SP will redirect the user during the SAML 2.0 Logout exchangeThere can be severalEach one might have a different binding (for example urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST)Each Service might have different URLs to receive a LogoutRequest message and a LogoutResponse messageThe X.509 certificate(s) corresponding to the private key used by the IdP to sign outgoing SAML 2.0 messages, such as the Assertion, LogoutRequest/LogoutResponse or ArtifactResponse messagesThe X.509 certificate(s) corresponding to the private key used by the IdP to decrypt incoming SAML 2.0 messages encrypted by remote SPs with the certificate(s), such as the NameID element inside a Logout RequestThe above only covers the Federation SSO setup. If the Federation partners support other services, such as Attribute Authority and Attribute Requester, then more Service URLs and certificate information need to be exchanged.Manual ProcessAs you can see, there can be a lot of information exchanged between the administrators responsible of managing the Federation servers, and any minor error might result in the Federation agreement not being set up properly and cause runtime errors.The errors that could occur due to a manual trust establishment could be:Wrong certificate usedIncorrect Service URL / binding combination, where for example an Assertion Consumer Service URL used only for Artifact binding is used for the HTTP-POST bindingTypo in the URLsIncorrectly specifying the hostname in the Service URLs: since cookies are used during Federation SSO operations, it is primordial to use the same fully qualified hostname, which is the public endpoint that users will use to access the Federation servers. (IP Addresses or non fully qualified hostnames will result in errors)Typo in the ProviderIDsURLs missingThose errors will result in:Signature verification or decryption failures when using incorrect certificatesServer throwing an error becauseCertificate is not validURLs are missing for the functionality that is exercised (for example Logout URL is missing)Inconsistent hostnames were used (fully qualified vs IP Address vs non fully qualified)ProviderID is unknown, caused by a typoInfinite loops, due to the use of inconsistent hostnames ...These errors listed above occur more than people assume, and this leads to time spent chasing down why Federation SSO is not working correctly, that almost point to a Federation Trust establishment mistake.Using SAML 2.0 MetadataThe SAML 2.0 specifications define the Metadata document which contains all the information a server has to know about its counterpart in order to perform Federation operations with that remote partner.This information includes:Service URLsSAML Bindings for those servicesCertificates for signature and encryption operationsWhich messages will be signed (AuthnRequest, Assertion)Roles supported by the Federation Server (IdP, SP, Attribute Authority...)The SAML 2.0 Metadata is typically generated by the Federation server itself and will be consumed by the partner's Federation server: so no manual intervention takes place to create and consume this document, reducing the number of potential errorsUsing SAML 2.0 Metadata offers the following advantages:All the information is contained in a single document The document is generated and consumed by the Federation servers (signatures might be used to protect against tampering with)No information is omittedThe data is consistent (same hostnames used in all URLs)More importantly, it saves time by reducing the possibility of mistakes during the Federation trust establishment, so that there will be fewer chances of runtime errors later on. In my next article, I will show how to use a database to store account linking information created during a Federation SSO, such as when the SAML 2.0 Persistent NameID is used.Cheers,Damien Carru

This article will cover the benefits of using SAML 2.0 Metadata when establishing trust between two SAML 2.0 Federation servers, as opposed to provide and enter information manually...

Custom Authentication Module in OIF/SP

In a previous article, I showed how to create a custom Authentication plugin and include it in an existing Federation Authentication Module. In this article I will create a new custom Authentication Module in OIF/SP that will be made of the existing OIF Federation Authentication Plugins and a custom plugin which willEvaluate the requested protected resourceDetermine the IdP to be used in the Federation SSO operationRequest a higher Federation Authentication Method from the IdP, depending on the resource being requested For more information on how to design a custom Authentication Plugin, refer to the OAM/OIF 11.1.2.2.0 Developer’s Guide,  which describes how to develop such a module.  I will focus here on how to:Implement the pluginCompile itPackage itUpload the plugin to OAMCreate a new Authentication ModuleEnjoy the reading!Federation Authentication ModuleAs explained in my previous article, an OAM Authentication Module is:A collection of Authentication PluginsAn orchestration determining the order of the execution of the pluginsThe OOTB Federation Authentication Module, called FederationPlugin, is made of two plugins:FedAuthnRequestPlugin: starts the Federation SSO flow, determines which IdP to use if not provided by a previous Authentication Plugin, creates an SSO request and redirects the user to the IdPAssertionProcessing: processes an incoming SAML/OpenID SSO Response and maps the message to a local user record in the LDAP directoryThe orchestration can be seen by:Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsoleNavigate to Access Manager -> Authentication ModulesOpen FederationSchemeClick on the Steps tab to see the pluginsClick on the Steps Orchestration tab to see the orchestration between the different plugins, and the plugin that will be used to start the operation FedAuthnRequestPlugin PluginThe FedAuthnRequestPlugin can consume information from a previous custom Authentication Plugin that will affect how the Federation SSO operation will be triggered.The AuthenticationContext instance shared between the Authentications Plugins contains CredentialParam objects that allow the various plugins to communicate at runtime. oracle.security.am.plugin.authn.AuthenticationContext: Context for the authentication operationShared across the various Authentication Pluginsoracle.security.am.plugin.authn.Credential:Collection of credentials dataStored in the AuthenticationContextoracle.security.am.plugin.authn.CredentialParam:Single credential parameterReferenced by a name, and has a type (string most of the time)Has a value, depending on the typeStored in the Credential instanceUsing that mechanism, the FedAuthnRequestPlugin can consume various types of information when starting a Federation SSO operation, stored in the Credential instance:IdP to perform Federation SSO withOptionalReferenced by the KEY_FEDIDP stringType: stringValue: IdP Partner NameThe Federation Authentication Method to request from the IdPOptionalReferenced by the KEY_FEDAUTHNMETHOD stringType: stringValue: the Federation Authentication Method that should be set in the SSO requestThe SAML 2.0 Federation Authentication Method Comparison atributeOptionalReferenced by the KEY_FEDAUTHNMETHODCOMP stringType: stringValue: the comparison to be used in the SAML 2.0 Authn Request messageexact for exactbetter for bettermin for minimummax for maximumThe Force Authn flagOptionalReferenced by the KEY_FEDFORCEAUTHN stringType: stringValue: the "true" or "false" string to indicate whether or not OIF/SP should request the IdP to challenge the user, even if the user is already authenticated at the IdPThe Is Passive flagOptionalReferenced by the KEY_FEDISPASSIVE stringType: stringValue: the "true" or "false" string to indicate whether or not the IdP is allowed to interact with the userCustom Authentication PluginOverviewThe custom Authentication Plugin will:Evaluate the requested resourceDetermine the IdP to be usedRequest a strong Federation Authentication Method from the IdP when a sensitive resource is requested, if the IdP supports a stronger Federation Authentication Method In the example, I have:Three IdP partners:AcmeIdP which supports the following Federation Authentication Methodsurn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport (default, no need to specifically request it)urn:oasis:names:tc:SAML:2.0:ac:classes:X509WorldBankurn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport (default, no need to specifically request it)urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKIWInsuranceIdPurn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport (default, no need to specifically request it)Three high level resources:http://company.com/businesspartners/acmebank, bound to AcmeIdP http://company.com/businesspartners/worldbank, bound to WorldBankhttp://company.com/businesspartners/worldinsurance, bound to WInsuranceIdPThree sensitive resources, for the three high level resources:http://company.com/businesspartners/acmebank/accounthttp://company.com/businesspartners/worldbank/accounthttp://company.com/businesspartners/worldinsurance/accountMy custom Authentication plugin will be made of the following:One Java class extending the oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn classA MANIFEST.MF file describing the Java classesAn XML file describing the pluginThose three elements will be bundled in a JAR file that is then uploaded to the OAM server via the OAM Administration Console. Once uploaded and activated I will create a Federation Authentication Module.Java ClassThe class implementing my custom Authentication plugin must adhere to the following:Extend the oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn classImplement the following methods:public ExecutionStatus process(AuthenticationContext context) throws AuthenticationExceptionMust return a status (failure or success)In my example, this method willEvaluate the requested resourceSet the KEY_FEDIDP CredentialParam to indicate the IdP to be usedSet the KEY_FEDAUTHNMETHOD CredentialParam to request a specific Federation Authentication Method from the IdPpublic String getPluginName()Returns the name of the custom pluginIn our example it will return "CustomIdPSelectionPlugin"public String getDescription()Returns a description of the custom Authentication PluginIn our example it will return "Custom IdP Selection Plugin"public Map<String, MonitoringData> getMonitoringData()Not used in an Authentication Plugin flowIn our example it will return nullpublic boolean getMonitoringStatus()Not used in an Authentication Plugin flowIn our example it will return falsepublic int getRevision()Must be the same value than the version specified in the manifest fileIn our example it will return 10public void setMonitoringStatus(boolean status)Not used in an Authentication Plugin flowIn our example this method will be emptyThe following code is an example of the custom plugin.package userauthn;import java.util.Map;import oracle.security.am.plugin.ExecutionStatus;import oracle.security.am.plugin.MonitoringData;import oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn;import oracle.security.am.plugin.authn.AuthenticationContext;import oracle.security.am.plugin.authn.AuthenticationException;import oracle.security.am.plugin.authn.CredentialParam;public class CustomIdPSelectionPlugin extends AbstractAuthenticationPlugIn{  public ExecutionStatus process(AuthenticationContext context)    throws AuthenticationException {    // requested URL    String resourceURL = context.getResourceURL();    // determines the IdP based on the request resource    String idpPartnerName = null;    if (resourceURL.startsWith("http://company.com/businesspartners/acmebank"))      idpPartnerName = "AcmeIdP";    else if (resourceURL.startsWith("http://company.com/businesspartners/worldbank"))      idpPartnerName = "WorldBank";    else if (resourceURL.startsWith("http://company.com/businesspartners/worldinsurance"))      idpPartnerName = "WInsuranceIdP";    // if IdP was determined, create a Credential param    // instance in the AuthenticationContext    // the OIF/SP FedAuthnRequestPlugin will consume it to start Federation SSO    if (idpPartnerName != null) {      CredentialParam idpParam = new CredentialParam();      idpParam.setName("KEY_FEDIDP");      idpParam.setType("string");      idpParam.setValue(idpPartnerName);      context.getCredential().addCredentialParam("KEY_FEDIDP", idpParam);    }    // here, the plugin will evaluate if the account subpath is being requested    // if it is, it will request from IdP higher Fed Auth Method    String fedAuthnMethod = null;    if ("AcmeIdP".equals(idpPartnerName) &&      resourceURL.startsWith("http://company.com/businesspartners/acmebank/account")) {      // AcmeIdP supports X.509 as the higher authentication method      fedAuthnMethod = "urn:oasis:names:tc:SAML:2.0:ac:classes:X509";    } else if ("WorldBank".equals(idpPartnerName) &&      resourceURL.startsWith("http://company.com/businesspartners/worldbank/account")) {      // WorldBank supports smart card as the higher authentication method      fedAuthnMethod = "urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI";    } else if ("WInsuranceIdP".equals(idpPartnerName) &&          resourceURL.startsWith("http://company.com/businesspartners/worldinsurance/account"))        {      // WInsuranceIdP does not support another fed authn method    }    // if another fed authn method was requested, create a Credential param    // instance in the AuthenticationContext    // the OIF/SP FedAuthnRequestPlugin will consume it to start Federation SSO    if (fedAuthnMethod != null) {      CredentialParam fedAuthnParam = new CredentialParam();      fedAuthnParam.setName("KEY_FEDAUTHNMETHOD");      fedAuthnParam.setType("string");      fedAuthnParam.setValue(fedAuthnMethod);      context.getCredential().addCredentialParam("KEY_FEDAUTHNMETHOD", fedAuthnParam);    }    // return success, which is mapped to FedAuthnRequestPlugin in the    // Authentication Module steps orchestration    return ExecutionStatus.SUCCESS;  }  public String getPluginName() {    return "CustomIdPSelectionPlugin";  }  public String getDescription() {    return "Custom IdP Selection Plugin";  }  public Map<String, MonitoringData> getMonitoringData() {    return null;  }  public boolean getMonitoringStatus() {    return false;  }  public int getRevision() {    return 10;  } public void setMonitoringStatus(boolean arg0) {  }}Plugin Registration FileThe custom Authentication plugin must be defined in a plugin XML file such as:<Plugin type="Authentication"><author>uid=admin</author><email>admin@example</email><creationDate>08:00:00,2014-01-15</creationDate><description>Custom IdP Selection Plugin</description><configuration></configuration></Plugin>Important Note: the XML file must have the same name as the class implementing the plugin, in this case CustomIdPSelectionPlugin.xmlSee the OAM/OIF 11.1.2.2.0 Developer’s Guide for more informationManifest FileBefore packaging the custom Authentication plugin in a JAR file, a MANIFEST.MF must be defined such as:    Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: CustomIdPSelectionPluginBundle-SymbolicName: CustomIdPSelectionPluginBundle-Version: 10Bundle-Activator: userauthn.CustomIdPSelectionPluginImport-Package: org.osgi.framework;version="1.3.0",oracle.security.am. plugin,oracle.security.am.plugin.authnBundle-RequiredExecutionEnvironment: JavaSE-1.6See the OAM/OIF 11.1.2.2.0 Developer’s Guide for more informationNote: the manifest file must include the Import-Package property which lists all the packages that are used in the pluginBuilding the PluginCompilingThe following JAR files from the OAM deployment need to be used for compilation:felix.jaroam-plugin.jarThese files are found in the following locations:felix.jar: $IAM_HOME/oam/server/lib/plugin/felix.jaroam-plugin.jar: $IAM_HOME/oam/server/lib/plugin/oam-plugin.jarIn my example, I put the CustomIdPSelectionPlugin.java file in a src/userautn folder:bash-4.1$ ls -l src/userauthn/total 4-rw-r--r-- 1 root root 3894 Mar 1 11:42 CustomIdPSelectionPlugin.javaTo compile, execute the following command:$JDK_HOME/bin/javac -cp $IAM_HOME/oam/server/lib/plugin/felix.jar:$IAM_HOME/oam/server/lib/plugin/oam-plugin.jar src/userauthn/*.javaPackaging the Custom PluginI created the MANIFEST.MF in the current directory based on the content listed in the previous section, and the CustomIdPSelectionPlugin.xml in the src directory, which contains the plugin definition listed in the previous section.find../MANIFEST.MF./src./src/userauthn./src/userauthn/CustomIdPSelectionPlugin.class./src/userauthn/CustomIdPSelectionPlugin.java./src/CustomIdPSelectionPlugin.xmlTo create the CustomIdPSelectionPlugin.jar JAR file that will contain the plugin and the required files, execute the following command:jar cfvm CustomIdPSelectionPlugin.jar MANIFEST.MF -C src/ .added manifestadding: userauthn/(in = 0) (out= 0)(stored 0%)adding: userauthn/CustomIdPSelectionPlugin.class(in = 2717) (out= 1267)(deflated 53%)adding: userauthn/CustomIdPSelectionPlugin.java(in = 3894) (out= 1055)(deflated 72%)adding: CustomIdPSelectionPlugin.xml(in = 234) (out= 155)(deflated 33%)This will create the CustomIdPSelectionPlugin.jar. To view the contents of the file:unzip -l CustomIdPSelectionPlugin.jarArchive:  CustomIdPSelectionPlugin.jar  Length      Date    Time    Name---------  ---------- -----   ----        0  03-01-2014 10:14   META-INF/      425  03-01-2014 10:14   META-INF/MANIFEST.MF        0  03-01-2014 10:13   userauthn/     2717  03-01-2014 10:13   userauthn/CustomIdPSelectionPlugin.class     3894  03-01-2014 09:56   userauthn/CustomIdPSelectionPlugin.java      234  03-01-2014 10:03   CustomIdPSelectionPlugin.xml---------                     -------     7270                     6 filesImportant Note: the JAR file must have the same name as the class implementing the plugin, in this case CustomIdPSelectionPlugin.jarDeploying the Custom Authentication PluginPerform the following steps to deploy the custom Authentication plugin in OAM:Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsoleNavigate to Access Manager -> PluginsClick Import Plug-InSelect the plugin JAR file (CustomIdPSelectionPlugin.jar in this example) The plugin will be in an uploaded state: You will need to distribute the plugin to the runtime OAM servers and activate it:Select the pluginClick Distribute SelectedThe Activation Status tab of the plugin will show the state of the plugin You will need to activate the plugin:Select the pluginClick Activate SelectedThe Activation Status tab of the plugin will show the state of the plugin Creating the Authentication ModuleI will now create a new Federation Authentication Module, based on the existing FederationPlugin Authentication Module, which will differ from the existing one:CustomIdPSelectionPlugin will be the initial stepOrchestration:On Success will be mapped FedAuthnRequestPlugin On Failure mapped to failureOn Error mapped to failurePerform the following steps to create a new Authentication Module:Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsoleNavigate to Access Manager -> Authentication ModulesClick Create Authentication ModuleSelect Create Custom Authentication ModuleEnter a Name (CustomFedModule for example) Perform the following steps to add steps to the new Authentication Module:Click on the Steps tabClick Add to add the FedAuthnRequestPlugin step:    Step name: FedAuthnRequestPluginPlug-in Name: FedAuthnRequestPluginClick OK Click Add to add the AssertionProcessing step:    Step name: AssertionProcessingPlug-in Name: FedUserAuthenticationPluginClick OK Click Add to add the IdPSelection step:    Step name: IdPSelection Plug-in Name: CustomIdPSelectionPluginClick OK The Steps tab will show: Perform the following steps to define the steps orchestration for the new Authentication Module:Click on the Steps Orchestration tabSelect IdPSelection as the Initial StepFor FedAuthnRequestPlugin:Select success for On SuccessSelect AssertionProcessing for On FailureSelect failure for On ErrorFor AssertionProcessing:Select success for On SuccessSelect failure for On FailureSelect failure for On ErrorFor IdPSelection:Select FedAuthnRequestPlugin for On SuccessSelect failure for On FailureSelect failure for On ErrorApply Authentication SchemeBefore being able to protect resources with an Authentication Policy that will use that new Authentication Module, a new Authentication Scheme needs to be created, referencing that new custom module. This is required, since the Authentication Policy is bound to an Authentication Scheme, not an Authentication Module.To create a new Authentication Scheme for that custom module, perform the following steps:Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsoleNavigate to Access Manager -> Authentication SchemesClick Create Authentication SchemeEnter a name (for example CustomFedScheme) and a descriptionSet the Authentication Level to an acceptable value (2 in my example)Select FORM as the Challenge MethodSet the Challenge Redirect URL (in my example, I set it to /oam/server/)Select the newly created custom Authentication Module (CustomFedModule in the example)Set the Challenge URL (/pages/servererror.jsp in this example)Set the Context Type (customWar for example)Set the Context Value (/oam here, since I don't use any pages)Enter the following for the Challenge Parameters at least:initial_command=NONEis_rsa=trueApply TestProtect a resource with an Authentication Policy using the newly created Authentication Scheme. This will invoke the custom Authentication Module.Voila! In my next article, I cover the benefits of using SAML 2.0 Metadata when setting up Federation between two servers.Cheers,Damien Carru

In a previous article, I showed how to create a custom Authentication plugin and include it in an existing Federation Authentication Module. In this article I will create a new custom Authentication...

Implementing an IdP Discovery Service

As discussed in my previous article, OIF/SP can be configured to use a remote IdP Discovery Service whose function is to determine which IdP to use for the Federation SSO operation.The "Identity Provider Discovery Service Protocol and Profile" SAML 2.0 specification published by OASIS defines the interaction protocol between a SAML 2.0 SP and an IdP Discovery Service.In this article, I will implement a sample IdP Discovery Service, and then I will configure OIF/SP to use that service:The service needs to support the protocol defined by the "Identity Provider Discovery Service Protocol and Profile" SAML 2.0 specification The service will be an HTTP service and can be deployed anywhereOIF/SP will be configured to redirect the user to that remote service when starting a Federation SSO operation.Enjoy the reading!IdP Discovery Service ProtocolAs mentioned in my previous article, the IdP Discovery Service flow is described in the specification (http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf?) and is made of the following steps:SP is configured to use a remote IdP Discovery Service to determine the IdP to be used for the Federation SSO operationThe SP redirects the user to the IdP Discovery Service via a 302 HTTP redirect and provides the following parameters in the query stringentityID: the Issuer/ProviderID of OIF/SPreturnIDParam: the name of the query string parameter that the service needs to use for the parameter containing the IdP ProviderID value, when redirecting the user back to OIF/SPreturn: the URL to use to redirect the user to OIF/SPThe service determines the IdP to useThe service redirects the user to OIF/SP via a 302 HTTP redirect based on the query parameter "return" specified by the SP and provides the following parameters in the query stringA query parameter containing the the IdP ProviderID value; the name of that query parameter is specified by the SP in the returnIDParam query parameter.Apart from the protocol exchange, the service can be implemented in any way deemed acceptable by the implementer. Custom ServiceOverviewIn this example, I will write a service that will:Be aware of a list of known IdPs, referenced by the ProviderID/Issuer identifiersLet the user select the IdP to use from a drop down listSave the user's choice in a cookie called IDPDiscServiceAt runtime, the service will check if the IDPDiscService is present:If present and contains a valid IdP, then the service will automatically redirect the user back to the SP with the IdP's ProviderID/Issuer: no user interaction will take placeOtherwise, the service will display a page containing a dropdown list of the known IdPsIn terms of implementation, I will:Use a JSP pageDeploy the WAR/JSP on a remote J2EE container, different from the WLS server where OAM/OIF are runningSample PagesMy custom IdP Discovery Service will be made of two JSP pages:landing.jspPage where the user is redirected from the SP to the serviceWill first check if the IDPDiscService cookie is present and contains a known IdPIf present, it will redirect the user back to the SP with the IdP's ProviderID/IssuerOtherwise it will display a page asking the user to select an IdPThe page asking the user to select an IdP will be made of a drop downUpon submitting the choice, the user will post data to /idpdiscoveryservice/submit.jsp pageThis page will be accessible via /idpdiscoveryservice/landing.jspsubmit.jspPage where the user posts its choice, from the landing.jspWill check that the selected IdP is valid Will save the IdP in the IDPDiscService cookieThe value will be the Base64 encoded IdP's ProviderID/IssuerThe cookie will be marked persistent Will redirect the user back to the SP with the IdP's ProviderID/IssuerImplementationLanding Page<%@ page buffer="5kb" autoFlush="true" session="false"%><%@ page language="java" import="java.util.*,sun.misc.*,java.net.*"%><%response.setHeader("Expires", "Sat, 1 Jan 2000 00:00:00 GMT");response.setHeader("Cache-Control", "no-cache");response.setHeader("Pragma", "no-cache");request.setCharacterEncoding("UTF-8");response.setContentType("text/html; charset=UTF-8");// list of known IdPs, keys being the displayed names, and values the ProviderID/Issuer IDsMap idps = new HashMap();idps.put("AcmeIdP", "https://acme.com/fed");idps.put("IdP1", "https://idp1.com/saml");idps.put("MyIdentiyProvider.com", "https://myidentityprovider.com/saml2.0");// entityID of the requesting SPString entityID = request.getParameter("entityID");// the query parameter that will contain the IdP's ProviderID/Issuer when// redirecting the user back to the SPString returnIDParam = request.getParameter("returnIDParam");// the URL where the user should be redirected at the SPString returnURL = request.getParameter("return");// check if the IDPDiscService cookie is set, and if it is a known IdPCookie[] cookies = request.getCookies();if (cookies != null && cookies.length > 0){  for (int i = 0; i < cookies.length; i++)  {    if ("IDPDiscService".equals(cookies[i].getName()))    {      // decode the idp      BASE64Decoder b64 = new BASE64Decoder();      String idp = new String(b64.decodeBuffer(cookies[i].getValue()));      if (idps.containsValue(idp))      {        // redirects to the SP        StringBuffer redirectStringBuffer = new StringBuffer(returnURL);        if (returnURL.indexOf('?') == -1)          redirectStringBuffer.append("?");        else if (returnURL.charAt(returnURL.length() - 1) != '&')          redirectStringBuffer.append("&");        redirectStringBuffer.append(returnIDParam);        redirectStringBuffer.append("=");        redirectStringBuffer.append(URLEncoder.encode(idp));        response.sendRedirect(redirectStringBuffer.toString());        return;      }    }  }}%><html>  <head>    <title>Select your Single Sign-On Server</title>  </head>  <body>    <p style="text-align: center;">Select your Single Sign-On Server</p>    <form action="/idpdiscoveryservice/submit.jsp" method="post" name="idpselection">      <input name="entityID" type="hidden" value="<%=entityID%>" />      <input name="returnIDParam" type="hidden" value="<%=returnIDParam%>" />      <input name="return" type="hidden" value="<%=returnURL%>" />      <p style="text-align: center;">Single Sign-On Server:        <select name="selectedidp"><%Iterator idpsIterator = idps.keySet().iterator();while(idpsIterator.hasNext()){  String displayIdP = (String)idpsIterator.next();  String providerIDIdP = (String)idps.get(displayIdP);%>          <option value="<%=providerIDIdP%>"><%=displayIdP%></option><%}%>        </select>      </p>      <p style="text-align: center;">        <input name="submit" type="submit" value="Submit" />      </p>    </form>  </body></html>Submit Page<%@ page buffer="5kb" autoFlush="true" session="false"%><%@ page language="java" import="java.util.*,sun.misc.*,java.net.*"%><%response.setHeader("Expires", "Sat, 1 Jan 2000 00:00:00 GMT");response.setHeader("Cache-Control", "no-cache");response.setHeader("Pragma", "no-cache");request.setCharacterEncoding("UTF-8");response.setContentType("text/html; charset=UTF-8");// list of known IdPs with values being the ProviderID/Issuer IDsList idps = new ArrayList();idps.add("https://acme.com/fed");idps.add("https://idp1.com/saml");idps.add("https://myidentityprovider.com/saml2.0");// entityID of the requesting SPString entityID = request.getParameter("entityID");// the query parameter that will contain the IdP's ProviderID/Issuer when// redirecting the user back to the SPString returnIDParam = request.getParameter("returnIDParam");// the URL where the user should be redirected at the SPString returnURL = request.getParameter("return");// the idp selected by the userString idp = request.getParameter("selectedidp");// check that the selected IdP is one of the known IdPsif (!idps.contains(idp))  throw new Exception("Unknown IdP");// save the idp in the IDPDiscService cookieBASE64Encoder b64Encoder = new BASE64Encoder();response.addHeader("Set-Cookie", "IDPDiscService=" +    b64Encoder.encode(idp.getBytes()) +    "; expires=Wed, 01-Jan-2020 00:00:00 GMT; path=/");// redirects to the SPStringBuffer redirectStringBuffer = new StringBuffer(returnURL);if (returnURL.indexOf('?') == -1)  redirectStringBuffer.append("?");else if (returnURL.charAt(returnURL.length() - 1) != '&')  redirectStringBuffer.append("&");redirectStringBuffer.append(returnIDParam);redirectStringBuffer.append("=");redirectStringBuffer.append(URLEncoder.encode(idp));response.sendRedirect(redirectStringBuffer.toString());%>PackagingHaving put the landing.jsp and submit.jsp into a directory only containing those files, I created the idpDiscService.war  WAR file using the JAR tool:jar cvf idpDiscService.war *.jspThe content of that WAR file can be seen via the unzip command:unzip -l idpDiscService.warArchive:  idpDiscService.war  Length      Date    Time    Name---------  ---------- -----   ----        0  01-09-2014 19:00   META-INF/       76  01-09-2014 19:00   META-INF/MANIFEST.MF     2898  01-09-2014 19:57   landing.jsp     1838  01-09-2014 19:57   submit.jsp---------                     -------     4812                     4 filesI then deployed this WAR file on a J2EE container, using /idpdiscoveryservice as the root path. That way both pages are accessible using /idpdiscoveryservice/landing.jsp and /idpdiscoveryservice/submit.jsp.Configuring OIF/SPTo configure OIF/SP to use an IdP Discovery Service, perform the following steps:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Enable/disable OIF/SP to use an IdP Discovery Service:putBooleanProperty("/spglobal/idpdiscoveryserviceenabled", "true")Set the location of the remote IdP Discovery Service:putStringProperty("/spglobal/idpdiscoveryserviceurl", "http://remote.idp.disc.service.com/idpdiscoveryservice/landing.jsp")Exit the WLST environment:exit()TestWhen OIF/SP is invoked to start a Federation SSO, it will redirect the user to my custom IdP Discovery Service (/idpdiscoveryservice/landing.jsp)On the first visit, the user will be presented with a drop down list and prompted to select an IdP SSO Server: Upon submitting the choice to /idpdiscoveryservice/submit.jsp, the page will validate the choice, save it into the IDPDiscService cookie and redirect the user to OIF/SP with the IdP's ProviderID: from there, OIF/SP will start Federation SSO with that IdP.The next times OIF/SP starts a Federation SSO for that user:The server will redirect the user to my custom IdP Discovery Service (/idpdiscoveryservice/landing.jsp)The page will detect the IDPDiscService cookie and decode the IdP's ProviderIDThe page will redirect the user to OIF/SP with the IdP's ProviderIDOIF/SP will start Federation SSO with that IdP. In the next article, I will show how to create a custom Authentication Module in OIF/SP that will be made of the existing OIF Federation Authentication Plugins and a custom plugin.Cheers,Damien Carru

As discussed in my previous article, OIF/SP can be configured to use a remote IdP Discovery Service whose function is to determine which IdP to use for the Federation SSO operation. The "Identity...

Using OAM Pre Authentication Advanced Rules in OIF IdP

Today I will showcase how to use the OAM Authentication Advanced Rule with OIF as an IdP with the following use case:OIF acts as the IdPA specific scheme is used to challenge all the usersThe OAM Authentication Policy for that scheme is configured to have a Pre-Authentication Advanced Rule that will evaluate if the browser is a desktop browser or a mobile browser If the user is using a desktop/laptop, then the configured Authentication Scheme will be usedOtherwise if the user is on a mobile, another scheme targeted for mobile platforms will be used, which will facilitate user interaction by using a mobile login pageFor more information about the Pre Authentication Advanced Rules in OAM, refer to the OAM/OIF 11.1.2.2.0 Administrator's GuideOAM Authentication Advanced RulesIn the 11.1.2.2.0 release of Oracle Access Manager, Advanced Rules for Authentication Policies were introduced:Pre Authentication Rules which allows an administrator to define a policy that will be evaluated when an OAM authentication operation is being performed, before the user is challenged by the Authentication SchemeThe rule can either block access Or instruct OAM to use a secondary Authentication Scheme to challenge the user, different than the one listed as the Authentication Scheme in the Authentication PolicyPost Authentication rules which allows an administrator to define a policy that will be evaluated after the Authentication Scheme was executed, to block access if necessary.The runtime data that can be evaluated by the OAM Authentication Advanced Rule is based on either the request, session or user data:Request data: this includes the information sent by the user's browser as well as the protected resource being requestedBrowser data HTTP headers (User-Agent, Cookie...)Location (IP Address, Proxy address...)Protected resource HostnamePortPathQuery String...Session Data if the rule is a Post Authentication RuleUser Data if the rule is a Post Authentication RuleThe OAM Administrator's guide lists the various properties that can be used.For example, the following Pre Authentication Rule could be used to route authentication requests for Smartphones to another OAM Authentication Scheme:request.userAgent.lower().find('iphone') > 0 or request.userAgent.lower().find('mobile') > 0 or request.userAgent.lower().find('blackberry') > 0 or request.userAgent.lower().find('android') > 0In this next example, the Post Authentication Rule indicates to deny access for users having opened more than 2 sessions:session.count > 2Note: Post Authentication Rules which are evaluated as Authentication Responses after Authentication are not evaluated in a Federation SSO flow, since OIF/IdP flow does not involve any Authentication Responses. To implement some Authorization based on the user's identity, Token Issuance Policies can be used, as discussed in this article.Advanced Rules with OIF/IdPFederation Authentication PoliciesWhen configuring OIF/IdP to use a specific OAM Authentication Scheme to challenge users at runtime, an intermediary OAM Authentication Policy will be created and bound to the specified OAM Authentication Scheme.In order to apply Authentication Advanced Rules within an IdP flow, we will need to modify those intermediary OAM Authentication Policies managed by the OIF administration modules.Out of the box, there are four Federation Authentication Policies existing in the IAM Suite Application Domain that are used by OIF/IdP to authenticate a user at runtime:LocalAuthnFederationBasicSchemeLocalAuthnFederationBasicFASchemeLocalAuthnFederationLDAPSchemeLocalAuthnFederationFAAuthScheme Additionally, Federation Authentication Policies will be created whenever a new OIF/IdP is configured to use another Authentication Scheme to challenge users during a Federation SSO operation.The name of the Federation Authentication Policy is based on the Authentication Scheme configured in OIF/IdP: "LocalAuthnFederation" + Name_of_the_Authentication_Scheme.Those policies should not be modified, except to define Pre and Post Authentication Rules.Defining an Advanced Rule for a Federation Authentication PolicyTo configure an Advanced Rule for a Federation Authentication Policy, perform the following steps:Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsoleNavigate to Access Manager -> Application DomainsClick Search and select the IAM Suite Application DomainClick on the Authentication Policies tabClick on the Federation Authentication Policy you wish to modifyClick on the Advanced Rules tab in that policyDefine a pre authentication policyApplyWe will see later an example of those steps.Federation Authentication MethodsAs mentioned in a previous article, it might be required to configure OIF/IdP to map any OAM Authentication Schemes used to challenge users to a Federation Authentication Methods, even the second Authentication Scheme that might be configured in a Pre Authentication Rule.This is done by using one of the OIF WSLT commands: addSPPartnerProfileAuthnMethod on an SP Partner Profile addSPPartnerAuthnMethod on an SP PartnerExampleIn this example, I will configure OIF to:Interact with a remote SP via the SAML 2.0 protocolHave the LDAPScheme as the default Authentication Scheme system wideHave the LocalAuthnFederationLDAPScheme Authentication Policy set up with a Pre Authentication Rule to use the BasicScheme if the client is a SmartphoneMap the LDAPScheme to the SAML 2.0 Federation Authentication Method urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransportMap the BasicScheme to the SAML 2.0 Federation Authentication Method urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransportDefault Scheme for OIF/IdPFirst let's configure OIF/IdP to use a default Authentication Scheme (even though that is the default scheme out of the box):Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setIdPDefaultScheme() command:setIdPDefaultScheme("LDAPScheme")Exit the WLST environment:exit()The consequence is that the LocalAuthnFederationLDAPScheme OAM Authentication Policy will now be used to challenge users for the remote SP partner.OAM Advanced Pre Authentication RuleLet's now create the Pre Authentication Rule that will indicate to OAM to use the BasicScheme for Smartphone users: the rule will be based on the User-Agent HTTP header:Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsoleNavigate to Access Manager -> Application DomainsClick Search and select the IAM Suite Application DomainClick on the Authentication Policies tabClick on the LocalAuthnFederationLDAPScheme policyClick on the Advanced Rules tab in that policyCreate a new Pre Authentication Rule Perform the following actions:Enter the information for the pre authentication rule:Rule Name: MobileUsersCondition: request.userAgent.lower().find('iphone') > 0 or request.userAgent.lower().find('mobile') > 0 or request.userAgent.lower().find('blackberry') > 0 or request.userAgent.lower().find('android') > 0Deny Access: uncheckedSwitch to Authentication Scheme: BasicScheme Perform the following actions:Click AddClick Apply Federation Authentication Method MappingsFinally, let's map the schemes that will be used in our deployments to SAML 2.0 Federation Authentication Methods (even though out of the box the mapping already exists for LDAPScheme and BasicScheme).In our environment, two schemes are used:LDAPScheme, configured in OIF/IdPBasicScheme, configured in the Pre Authentication RuleWe will map both schemes to urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport at the partner profile level:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the addSPPartnerProfileAuthnMethod() command:addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "LDAPScheme")addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "BasicScheme")Exit the WLST environment:exit()Test When performing Federation SSO from a desktop/laptop browser, OIF/IdP will challenge with the LDAPScheme and the user will see the following login page: While a Smartphone user for a Federation SSO operation with the same SP partner would see an HTTP Basic Authentication challenge: In my next article, I will show how to implement an IdP Discovery Service.Cheers,Damien Carru

Today I will showcase how to use the OAM Authentication Advanced Rule with OIF as an IdP with the following use case: OIF acts as the IdP A specific scheme is used to challenge all the users The OAM...

Custom Post-Authentication Module in OIF / SP

In this article, I will show how to implement a custom authentication plugin that will be invoked after Federation SSO is complete and that will: Access the information contained in the SAML Assertion (IdP name, user attributes...) Update the LDAP user attributes based on the SAML User attributes For more information on how to design a custom Authentication Plugin, refer to the OAM/OIF 11.1.2.2.0 Developer’s Guide, chapter 3, which describes how to develop such a module: http://docs.oracle.com/cd/E40329_01/dev.1112/e27134/authnapi.htm.   I will focus here on how to: Implement the plugin Compile it Package it Upload the plugin to OAM Create a new Federation Authentication Module Enjoy the reading! Federation Authentication Module Important note: when using the Federation Test SP application, the Authentication Module is by-passed and as such, the plugins defined in such a module won't be executed. An OAM Authentication Module is: A collection of Authentication Plugins An orchestration determining the order of the execution of the plugins The OOTB Federation Authentication Module, called FederationPlugin, is made of two plugins: FedAuthnRequestPlugin: starts the Federation SSO flow, determines which IdP to use if not provided by a previous Authentication Plugin, creates an SSO request and redirects the user to the IdP AssertionProcessing: processes an incoming SAML/OpenID SSO Response and maps the message to a local user record in the LDAP directory The orchestration can be seen by: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Authentication Modules Open FederationScheme Click on the Steps tab to see the plugins Click on the Steps Orchestration tab to see the orchestration between the different plugins, and the plugin that will be used to start the operation AssertionProcessing Plugin The AssertionProcessing plugin is responsible for the validation and consumption of an incoming SSO Assertion, for the mapping of the Assertion to a local LDAP user record and will return the user's identity as well as the content of the Assertion to OAM. The AuthenticationContext instance shared between the Authentications Plugins contains CredentialParam objects that allow the various plugins to communicate at runtime as well as the result of the authentication operation. oracle.security.am.plugin.authn.AuthenticationContext: Context for the authentication operation Shared across the various Authentication Plugins oracle.security.am.plugin.authn.Credential: Collection of credentials data Stored in the AuthenticationContext oracle.security.am.plugin.authn.CredentialParam: Single credential parameter Referenced by a name, and has a type (string most of the time) Has a value, depending on the type Stored in the Credential instance Authentication Context Data Upon successful authentication, an OAM Authentication Plugin returns the following data in the AuthenticationContext: The JaaS Subject identifying the user, with the following Principal instances: oracle.security.am.common.utilities.principal.OAMUserPrincipal whose name contains the userID oracle.security.am.common.utilities.principal.OAMUserDNPrincipal whose name contains the user's DN oracle.security.am.common.utilities.principal.OAMGUIDPrincipal if present, whose name contains the user's GUID The following CredentialParam instances contained in the Credential object of the AuthenticationContext The user's DN Referenced by the KEY_USERNAME_DN string Type: string Value: the user's DN The following PluginResponse instances contained in the AuthenticationContext: The userID Referenced by the KEY_AUTHENTICATED_USER_NAME string Type: PluginAttributeContextType.LITERAL Value: the userID The name of the Identity Store where the user record is located Referenced by the KEY_IDENTITY_STORE_REF string Type: PluginAttributeContextType.LITERAL Value: the OAM ID Store name The Authentication Level if it was overridden during the Federation SP processing  (see this article for more information: Art 27 - Mapping Fed Authn Method to Authn Levels in OIF SP) Referenced by the KEY_AUTHN_LEVEL string Type: PluginAttributeContextType.LITERAL Value: authn level as a string Assertion data, with each element being a standalone PluginResponse instance: Referenced by its name (see below) Type: PluginAttributeContextType.SESSION Value: a string object The data contained in the AuthenticationContext is used by OAM for further processing. The Assertion data is made of the following elements: IdP partner name, referenced by fed.partner The SAML NameID Format, referenced by fed.nameidformat The NameID value, referenced by fed.nameidvalue User attributes contained in the Assertion, referenced by fed.attr.ATTRIBUTE_NAME, with ATTRIBUTE_NAME being Either the name of the attribute contained in the Assertion, if no IdP Attribute Profile mapped the name to a local OAM Session Attribute Name Or the name of the OAM Session Attribute Name which is the result of the mapping of the name of the attribute in the Assertion to a local OAM Session Attribute Name based on the IdP Attribute Profile used for the IdP Partner. Example Let's take the following example to examine the data that would be returned by the AssertionProcessing plugin at the end of the flow: OIF acts as an SP The partner IdP is a SAML 2.0 IdP registered as acmeIdP in the OIF/SP server, and the IdP's ProviderID/Issuer is http://acme.com/idp The IdP sends a SAML 2.0 Assertion containing NameID of format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, with the value being the user's email address Three SAML Attributes Name set to uid containing the userID Name set to lastname containing the user's last name Name set to firstname containing the user's first name The IdP partner in OIF/SP is bound to an IdP Attribute Profile with only one entry, which maps the SAML Attribute Name uid to the OAM Session Attribute Name userid In the example, the test user will be alice: UserID at OIF/SP alice Attributes sent in the SAML Assertion: userID: alice lastname: Appleton fistname: Alice Email address for alice is alice@oracle.com An example of the SAML 2.0 Assertion would be: <samlp:Response ..>    <saml:Issuer ...>http://acme.com/idp</saml:Issuer>    <samlp:Status>        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>    </samlp:Status>    <saml:Assertion ...>        <saml:Issuer ...>http://acme.com/idp</saml:Issuer>        <dsig:Signature ...>        ...        </dsig:Signature>        <saml:Subject> <saml:NameID ...>alice@oracle.com</saml:NameID>            ...        </saml:Subject>        <saml:Conditions ...>         ...        </saml:Conditions>        <saml:AuthnStatement ...>        ...        </saml:AuthnStatement>        <saml:AttributeStatement ...>            <saml:Attribute Name="userid" ...>                <saml:AttributeValue ...>alice</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="lastname" ...>                <saml:AttributeValue ...>Appleton</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="firstname" ...>                <saml:AttributeValue ...>Alice</saml:AttributeValue>            </saml:Attribute>        </saml:AttributeStatement>    </saml:Assertion></samlp:Response> After a successful processing of the SAML 2.0 Assertion and the mapping of the incoming SSO response to a local user record, the AssertionProcessing plugin will return to OAM the AuthenticationContext with the following data: The Subject containing: oracle.security.am.common.utilities.principal.OAMUserPrincipal with name set to alice (alice's local userID) oracle.security.am.common.utilities.principal.OAMUserDNPrincipal with name set to cn=alice,ou=users,dc=us,dc=oracle,dc=com (alice's local DN) oracle.security.am.common.utilities.principal.OAMGUIDPrincipal with name set to alice's local GUID The following CredentialParam instances contained in the Credential object of the AuthenticationContext KEY_USERNAME_DN with value set to cn=alice,ou=users,dc=us,dc=oracle,dc=com (alice's local DN) The following PluginResponse instances contained in the AuthenticationContext: KEY_AUTHENTICATED_USER_NAME with string value set to alice (alice's local userID), with type set to literal KEY_IDENTITY_STORE_REF with string value set to IDStore (name of local OAM ID Store), with type set to literal fed.partner with string value set to acmeIdP (local IdP Partner name), with type set to session fed.nameidformat with string value set to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, with type set to session fed.nameidvalue with string value set to alice@oracle.com , with type set to session fed.attr.uid with string value set to alice, with type set to session (the name of the attribute was mapped from userid to uid because of the IdP Attribute Profile) fed.attr.lastname with string value set to Appleton, with type set to session fed.attr.firstname with string value set to Alice, with type set to session Custom Authentication Plugin Overview In this article, let's assume that the OIF/SP deployment needs to support: Creation/provisioning of user accounts when the user is redirected to OIF/SP but does not have a local account: the newly created account will be populated with the SAML 2.0 Assertion data Automatic updates of the user account so that the LDAP user attributes are refreshed with the latest SAML 2.0 Assertion data. Using a Just-In-Time User Provisioning module as discussed in an earlier article will provide support for #1. To be able to meet the requirements for #2, a custom Authentication Plugin will be needed that will: Be invoked after a successful processing of the AssertionProcessing plugin Examine the data extracted from the SAML 2.0 Assertion Connect to LDAP and eventually update the LDAP user attributes For this example, the environment is made of: OIF as a SAML 2.0 SP The partner IdP is a SAML 2.0 IdP registered as acmeIdP in the OIF/SP server, and the IdP's ProviderID/Issuer is http://acme.com/idp The IdP sends a SAML 2.0 Assertion containing NameID of format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, with the value being the user's email address Three SAML Attributes Name set to uid containing the userID Name set to lastname containing the user's last name Name set to firstname containing the user's first name The IdP partner in OIF/SP is bound to an IdP Attribute Profile with only one entry, which maps the SAML Attribute Name uid to the OAM Session Attribute Name userid My custom Authentication plugin will be made of the following: One Java class extending the oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn class A MANIFEST.MF file describing the Java classes An XML file describing the plugin Those three elements will be bundled in a JAR file that is then uploaded to the OAM server via the OAM Administration Console. Once uploaded and activated I will modify the Federation Authentication Module. Java Class The class implementing my custom Authentication plugin must adhere to the following: Extend the oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn class Implement the following methods: public ExecutionStatus process(AuthenticationContext context) throws AuthenticationException Must return a status (failure or success) In my example, this method will Retrieve the Assertion data and the user DN Connect to LDAP and update the user record attributes based on the Assertion data public String getPluginName() Returns the name of the custom plugin In our example it will return "CustomAttributesUpdatePlugin" public String getDescription() Returns a description of the custom Authentication Plugin In our example it will return "Custom Attributes Update Plugin" public Map<String, MonitoringData> getMonitoringData() Not used in an Authentication Plugin flow In our example it will return null public boolean getMonitoringStatus() Not used in an Authentication Plugin flow In our example it will return false public int getRevision() Must be the same value than the version specified in the manifest file In our example it will return 10 public void setMonitoringStatus(boolean status) Not used in an Authentication Plugin flow In our example this method will be empty The following code is an example of the custom plugin. package postsp;import java.util.Hashtable;import java.util.Map;import java.util.Set;import javax.naming.Context;import javax.naming.NamingException;import javax.naming.directory.Attributes;import javax.naming.directory.BasicAttribute;import javax.naming.directory.BasicAttributes;import javax.naming.directory.DirContext;import javax.naming.directory.InitialDirContext;import javax.security.auth.Subject;import oracle.security.am.common.utilities.principal.OAMUserDNPrincipal;import oracle.security.am.common.utilities.principal.OAMUserPrincipal;import oracle.security.am.plugin.ExecutionStatus;import oracle.security.am.plugin.MonitoringData;import oracle.security.am.plugin.PluginAttributeContextType;import oracle.security.am.plugin.PluginResponse;import oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn;import oracle.security.am.plugin.authn.AuthenticationContext;import oracle.security.am.plugin.authn.AuthenticationException;public class CustomAttributesUpdatePlugin extends AbstractAuthenticationPlugIn{  public ExecutionStatus process(AuthenticationContext context)              throws AuthenticationException {    // user's ID and DN. Note: I am not making necessary checks for size/null to    // keep the sample code minimal.    Subject subject = context.getSubject();    Set<OAMUserPrincipal> principalsUserID =              subject.getPrincipals(OAMUserPrincipal.class);    Set<OAMUserDNPrincipal> principalsDN =              subject.getPrincipals(OAMUserDNPrincipal.class);    String localUserID = (String)principalsUserID.iterator().next().getName();    String localUserDN = (String)principalsDN.iterator().next().getName();    // get the assertion data. Note: I am not making necessary checks for size/null to    // keep the sample code minimal.    PluginResponse partnerResponse = context.getResponse(              PluginAttributeContextType.SESSION, "fed.partner");    String partnerName = (String)partnerResponse.getValue();    PluginResponse nameIDResponse = context.getResponse(              PluginAttributeContextType.SESSION, "fed.nameidvalue");    String nameID = (String)nameIDResponse.getValue();    PluginResponse uidResponse = context.getResponse(              PluginAttributeContextType.SESSION, "fed.attr.uid");    String uid = (String)uidResponse.getValue();    PluginResponse firstnameResponse = context.getResponse(              PluginAttributeContextType.SESSION, "fed.attr.firstname");    String firstname = (String)firstnameResponse.getValue();    PluginResponse lastnameResponse = context.getResponse(              PluginAttributeContextType.SESSION, "fed.attr.lastname");    String lastname = (String)lastnameResponse.getValue();    try {      // open ldap connection       Hashtable env = new Hashtable();      env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");      env.put(Context.PROVIDER_URL, "ldap://host:port");      env.put(Context.SECURITY_PRINCIPAL, "admin");      env.put(Context.SECURITY_CREDENTIALS, "password");      DirContext ldapContext = new InitialDirContext(env);      // modify user ldap record. Note: I am not making the necessary checks to      // keep the sample code minimal.      Attributes attributes = new BasicAttributes();      attributes.put(new BasicAttribute("givenname", firstname));      attributes.put(new BasicAttribute("sn", lastname));      attributes.put(new BasicAttribute("mail", nameID));      attributes.put(new BasicAttribute("uid", uid));      ldapContext.modifyAttributes(localUserDN,                         DirContext.REPLACE_ATTRIBUTE, attributes);    }    catch (NamingException ex) {      throw new AuthenticationException(ex);    }    // return success, so that OAM can resume the flow    return ExecutionStatus.SUCCESS;  }  public String getPluginName() {    return "CustomAttributesUpdatePlugin";  }  public String getDescription() {    return "Custom Attributes Update Plugin";  }  public Map<String, MonitoringData> getMonitoringData() {    return null;  }  public boolean getMonitoringStatus() {    return false;  }  public int getRevision() {    return 10;  }  public void setMonitoringStatus(boolean arg0) {  }} Plugin Registration File The custom Authentication plugin must be defined in a plugin XML file such as: <Plugin type="Authentication"><author>uid=admin</author><email>admin@example</email><creationDate>08:00:00,2014-01-15</creationDate><description>Custom Attributes Update Plugin</description><configuration></configuration></Plugin> Important Note: the XML file must have the same name as the class implementing the plugin, in this case CustomAttributesUpdatePlugin.xml See the OAM/OIF 11.1.2.2.0 Developer’s Guide for more information Manifest File Before packaging the custom Authentication plugin in a JAR file, a MANIFEST.MF must be defined such as:    Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: CustomAttributesUpdatePluginBundle-SymbolicName: CustomAttributesUpdatePluginBundle-Version: 10Bundle-Activator: postsp.CustomAttributesUpdatePluginImport-Package: org.osgi.framework;version="1.3.0",oracle.security.am. plugin,oracle.security.am.plugin.authn,oracle.security.am.common.util ities.principal,javax.naming,javax.naming.directory,javax.security.au thBundle-RequiredExecutionEnvironment: JavaSE-1.6 See the OAM/OIF 11.1.2.2.0 Developer’s Guide for more information Note: the manifest file must include the Import-Package property which lists all the packages that are used in the plugin Building the Plugin Compiling The following JAR files from the OAM deployment need to be used for compilation: felix.jar oam-plugin.jar utilities.jar These files are found in the following locations: felix.jar: $IAM_HOME/oam/server/lib/plugin/felix.jar oam-plugin.jar: $IAM_HOME/oam/server/lib/plugin/oam-plugin.jar utilities.jar: $IAM_HOME/oam/server/lib/plugin/utilities.jar In my example, I put the CustomAttributesUpdatePlugin.java file in a src/postsp folder: bash-4.1$ ls -l src/postsp/total 4-rw-r--r-- 1 root root 4377 Oct  1 09:54 CustomAttributesUpdatePlugin.java To compile, execute the following command: $JDK_HOME/bin/javac -cp $IAM_HOME/oam/server/lib/plugin/felix.jar:$IAM_HOME/oam/server/lib/plugin/oam-plugin.jar:$IAM_HOME/oam/server/lib/plugin/utilities.jar src/postsp/*.java Packaging the Custom Plugin I created the MANIFEST.MF in the current directory based on the content listed in the previous section, and the CustomAttributesUpdatePlugin.xml in the src directory, which contains the plugin definition listed in the previous section. find../MANIFEST.MF./src./src/userauthn./src/userauthn/CustomAttributesUpdatePlugin.class./src/userauthn/CustomAttributesUpdatePlugin.java./src/CustomAttributesUpdatePlugin.xml To create the CustomAttributesUpdatePlugin.jar JAR file that will contain the plugin and the required files, execute the following command: jar cfvm CustomAttributesUpdatePlugin.jar MANIFEST.MF -C src/ .added manifestadding: CustomAttributesUpdatePlugin.xml(in = 238) (out= 158)(deflated 33%)adding: postsp/(in = 0) (out= 0)(stored 0%)adding: postsp/CustomAttributesUpdatePlugin.java(in = 4377) (out= 1206)(deflated 72%)adding: postsp/CustomAttributesUpdatePlugin.class(in = 3726) (out= 1667)(deflated 55%) This will create the CustomAttributesUpdatePlugin.jar. To view the contents of the file: unzip -l CustomAttributesUpdatePlugin.jarArchive:  CustomAttributesUpdatePlugin.jar  Length      Date    Time    Name---------  ---------- -----   ----        0  10-01-2014 10:04   META-INF/      542  10-01-2014 10:04   META-INF/MANIFEST.MF      238  10-01-2014 09:11   CustomAttributesUpdatePlugin.xml        0  10-01-2014 09:59   postsp/     4377  10-01-2014 09:54   postsp/CustomAttributesUpdatePlugin.java     3726  10-01-2014 09:54   postsp/CustomAttributesUpdatePlugin.class---------                     -------     8883                     6 Important Note: the JAR file must have the same name as the class implementing the plugin, in this case CustomAttributesUpdatePlugin.jar Deploying the Custom Authentication Plugin Perform the following steps to deploy the custom Authentication plugin in OAM: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Plugins Click Import Plug-In Select the plugin JAR file (CustomAttributesUpdatePlugin.jar in this example) The plugin will be in an uploaded state: You will need to distribute the plugin to the runtime OAM servers and activate it: Select the plugin Click Distribute Selected The Activation Status tab of the plugin will show the state of the plugin You will need to activate the plugin: Select the plugin Click Activate Selected The Activation Status tab of the plugin will show the state of the plugin Creating the Authentication Module I will now create a new Federation Authentication Module, based on the existing FederationPlugin Authentication Module, which will differ from the existing one: CustomAttributesUpdatePlugin will be the step invoked after a success result from the AssertionProcessing plugin Orchestration: On Success will be mapped success On Failure will be mapped to failure On Error will be mapped to failure Perform the following steps to create a new Authentication Module: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Authentication Modules Click Create Authentication Module Select Create Custom Authentication Module Enter a Name (CustomFedModule for example) Perform the following steps to add steps to the new Authentication Module: Click on the Steps tab Click Add to add the FedAuthnRequestPlugin step:    Step name: FedAuthnRequestPlugin Plug-in Name: FedAuthnRequestPlugin Click OK Click Add to add the AssertionProcessing step:    Step name: AssertionProcessing Plug-in Name: FedUserAuthenticationPlugin Click OK Click Add to add the AttributesUpdate step:    Step name: AttributesUpdate Plug-in Name: CustomAttributesUpdatePlugin Click OK The Steps tab will show: Perform the following steps to define the steps orchestration for the new Authentication Module: Click on the Steps Orchestration tab Select FedAuthnRequestPlugin as the Initial Step For FedAuthnRequestPlugin: Select success for On Success Select AssertionProcessing for On Failure Select failure for On Error For AssertionProcessing: Select AttributesUpdate for On Success Select failure for On Failure Select failure for On Error For AttributesUpdate: Select success for On Success Select failure for On Failure Select failure for On Error Apply Authentication Scheme Before being able to protect resources with an Authentication Policy that will use that new Authentication Module, a new Authentication Scheme needs to be created, referencing that new custom module. This is required, since the Authentication Policy is bound to an Authentication Scheme, not an Authentication Module. To create a new Authentication Scheme for that custom module, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Authentication Schemes Click Create Authentication Scheme Enter a name (for example CustomFedScheme) and a description Set the Authentication Level to an acceptable value (2 in my example) Select FORM as the Challenge Method Set the Challenge Redirect URL (in my example, I set it to /oam/server/) Select the newly created custom Authentication Module (CustomFedModule in the example) Set the Challenge URL (/pages/servererror.jsp in this example) Set the Context Type (customWar for example) Set the Context Value (/oam here, since I don't use any pages) Enter the following for the Challenge Parameters at least: initial_command=NONE is_rsa=true Apply Test Protect a resource with an Authentication Policy using the newly created Authentication Scheme. This will invoke the custom Authentication Module. Prior to the Federation SSO, the LDAP user record for alice at OAM/OIF/SP is: dn: cn=alice,ou=users,dc=us,dc=oracle,dc=comobjectClass: personobjectClass: organizationalPersonobjectClass: inetOrgPersonobjectClass: topgivenName: altitle: manageruid: alicecn: alicesn: APPLETONuserPassword:: e1NTSEE1MTJ9TXp0R2d0Si9GT1NzYUxvRXJqZW0rM1Q2eU5QMW9ZZmZ2Y3FkVWp aS1o1OFNGMy95ZDBueUxUbnllRi83SFRtS2JmOTJ0anY4TFd6di9UanliOGw4WFNQV1BxSnF3NGd6mail: alice@oracle.com After authentication, the IdP will send the following information for user alice in the SAML 2.0 Assertion: SAML Attributes: userID: alice lastname: Appleton fistname: Alice SAML NameID: alice@oracle.com After Federation SSO, the CustomAttributesUpdatePlugin will have updated alice's LDAP record so that sn, givenname, uid and mail are set to the values from the SAML Assertion. The LDAP user record for alice after the Federation SSO operation at OAM/OIF/SP is now: dn: cn=alice,ou=users,dc=us,dc=oracle,dc=comobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topgivenName: Alicetitle: manageruid: alicecn: alicesn: AppletonuserPassword:: e1NTSEE1MTJ9TXp0R2d0Si9GT1NzYUxvRXJqZW0rM1Q2eU5QMW9ZZmZ2Y3FkVWp aS1o1OFNGMy95ZDBueUxUbnllRi83SFRtS2JmOTJ0anY4TFd6di9UanliOGw4WFNQV1BxSnF3NGd6mail: alice@oracle.com In my next article, I will showcase the use ofan OAM Pre Authentication Rule with OIF/IdPe.Cheers,Damien Carru

In this article, I will show how to implement a custom authentication plugin that will be invoked after Federation SSO is complete and that will: Access the information contained in the SAML...

Determining which IdP to use for Federation SSO

As a Service Provider, when triggering a Federation SSO operation, the main challenge sometimes lies with determining which IdP will be selected for the SSO flow, in cases where the SP has trust agreements with multiple IdPs. OIF/SP has different mechanism to select the IdP for the Federation SSO operation, including: Having the OAM Federation Scheme indicating the IdP to be used Having a custom OAM Authentication Plugin setting the IdP to be used Using a SAML 2.0 IdP Discovery Service if the IdP was neither specified by the Scheme nor by a custom plugin Using the Default SSO IdP if no IdP Discovery Service is used This article will explore each mechanism more closely. OAM Federation Scheme OIF provides administration tools to create an OAM Authentication Scheme which will be: A Federation Scheme Bound to a specific IdP Partner When a resource is protected with that kind of Authentication Scheme, and if a non authenticated user requests access, a Federation SSO flow will be triggered with the IdP Partner to which the scheme is bound. Creating such schemes allows an administrator to have specific resources which will result in a Federation SSO with specific IdP Partners. Note: if the user is already authenticated with a valid session which has a level strong enough, accessing resources protected by other Federation Schemes might not result in a new Federation SSO OAM Administration Console To create an OAM Authentication Scheme for a specific IdP Partner, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Open the IdP Partner for which you want to create the scheme Click on the "Create Authentication Scheme and Module" button The OAM Administration Console will create: An OAM Authentication Module bound to this IdP Partner named <PARTNER_NAME>FederationPlugin An OAM Authentication Scheme bound to the newly created OAM Authentication Module named <PARTNER_NAME>FederationScheme WLST Command To create an OAM Authentication Scheme for a specific IdP Partner using the OIF WLST createAuthnSchemeAndModule() command, execute the following steps: 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 createAuthnSchemeAndModule() command Specify the IdP Partner Name An example would be:createAuthnSchemeAndModule("AcmeIdP") Exit the WLST environment:exit() Note: to delete such a Federation Scheme/Module, execute the OIF WLST deleteAuthnSchemeAndModule() command. Protecting a Resource To protect a resource with a <PARTNER_NAME>FederationScheme that will trigger Federation SSO with that specific IdP Partner, , execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domain Click Search and open the Application Domain containing the resources you wish to protect with the new FederationScheme Click on the Authentication Policies tab Create a new Authentication Policy or edit an existing one Select the new FederationScheme Apply After this change, whenever a user requests resources protected by this Authentication Policy and that the user needs to be authenticated, then a Federation SSO will be executed with the specific IdP Partner (AcmeIdP in this example). Custom OAM Authentication Plugin Overview An OAM Authentication Module is: A collection of Authentication Plugins An orchestration determining the order of the execution of the plugins The OOTB Federation Authentication Module, called FederationPlugin, is made of two plugins: FedAuthnRequestPlugin: starts the Federation SSO flow, determines which IdP to use, creates an SSO request and redirects the user to the IdP AssertionProcessing: processes an incoming SAML/OpenID SSO Response and maps the message to a local user record in the LDAP directory The orchestration can be seen by: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Authentication Modules Open FederationScheme Click on the Steps tab to see the plugins Click on the Steps Orchestration tab to see the orchestration between the different plugins, and the plugin that will be used to start the operation Implementing a Custom Plugin A custom plugin can be implemented based on the OAM Custom Authentication Plugin framework that will determine the IdP to be used for a specific Federation SSO operation: The plugin will determine which IdP needs to be used via a specific approach (cookie, user selection via a page, programmatic...) Once the selection is done, the plugin will need to save the IdP Partner name in Credential instance that will be saved into the AuthenticationContext The plugin would return a success status OAM would invoke the next plugin (FedAuthnRequestPlugin) which would retrieve the IdP Partner Name from the AuthenticationContext The Federation SSO would be started with that IdP The code to save the IdP Partner name in the AuthenticationContext would be similar to: public ExecutionStatus process(AuthenticationContext context){   ...   CredentialParam param = new CredentialParam();   param.setName("KEY_FEDIDP");   param.setType("string");   param.setValue(IDP_PARTNER_NAME);   context.getCredential().addCredentialParam("KEY_FEDIDP", param);   ...   return ExecutionStatus.SUCCESS;} Once that plugin is implemented: It will need to be packaged, uploaded, distributed and activated A new Authentication Module will need to be created with three plugins The custom plugin FedAuthnRequestPlugin AssertionProcessing The orchestration will need to be set with: The custom plugin being the Initial Step Custom Plugin: On Success, FedAuthnRequestPlugin should be invoked On Failure, failure should be returned On Error, failure should be returned FedAuthnRequestPlugin : On Success, success should be returned On Failure, AssertionProcessing should be invoked On Error, failure should be returned Custom Plugin: On Success, success should be returned On Failure, failure should be returned On Error, failure should be returned A new OAM Authentication Scheme should be created, using the new OAM Authentication Module. The new scheme should be similar to the OOTB FederationScheme Finally, resources can now be protected using the new OAM Scheme that will use the custom Authentication Module/Plugins to perform the Federation SSO operation. Note: see more information about custom plugins in the OAM Developer's guide. IdP Discovery Service Overview The "Identity Provider Discovery Service Protocol and Profile" SAML 2.0 specification defines a way for SAML 2.0 SPs to delegate the IdP selection to a remote service. The flow is described in the SAML 2.0 specification and is made of the following steps: SP is configured to use a remote IdP Discovery Service to determine the IdP to be used for the Federation SSO operation The SP redirects the user to the IdP Discovery Service via a 302 HTTP redirect and provides the following parameters in the query string entityID: the Issuer/ProviderID of OIF/SP returnIDParam: the name of the query string parameter that the service needs to use for the parameter containing the IdP ProviderID value, when redirecting the user back to OIF/SP return: the URL to use to redirect the user to OIF/SP The service determines the IdP to use The service redirects the user to OIF/SP via a 302 HTTP redirect based on the query parameter "return" specified by the SP and provides the following parameters in the query string A query parameter containing the the IdP ProviderID value; the name of that query parameter is specified by the SP in the returnIDParam query parameter. Configuring OIF/SP OIF/SP can be configured to use any remote IdP Discovery Service. Also, OIF includes a simple IdP Discovery Service that can be used and that lets user choose which IdP to perform Federation SSO with. To configure OIF/SP to use an IdP Discovery Service, perform the following steps: 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() Enable/disable OIF/SP to use an IdP Discovery Service:putBooleanProperty("/spglobal/idpdiscoveryserviceenabled", "true/false") To enable:putBooleanProperty("/spglobal/idpdiscoveryserviceenabled", "true") To disableputBooleanProperty("/spglobal/idpdiscoveryserviceenabled", "false") Set the location of the remote IdP Discovery Service:putStringProperty("/spglobal/idpdiscoveryserviceurl", "URL") Replace URL by the location of the service For the bundled simple IdP Discovery Service, replace URL by /oamfed/discovery.jsp (this is the OOTB value for this property):putStringProperty("/spglobal/idpdiscoveryserviceurl", "/oamfed/discovery.jsp") For a remote service, an example would be:putStringProperty("/spglobal/idpdiscoveryserviceurl", "http://sp.com/discovery") Exit the WLST environment:exit() To use the bundled simple IdP Discovery Service, perform the following steps: 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() Enable/disable the bundled IdP Discovery Service:putBooleanProperty("/spglobal/idpdiscoveryservicepageenabled", "true/false") To enable:putBooleanProperty("/spglobal/idpdiscoveryservicepageenabled", "true") To disableputBooleanProperty("/spglobal/idpdiscoveryservicepageenabled", "false") Exit the WLST environment:exit() Test In my test environment, I have three IdPs: AcmeIdP: SAML 2.0 IdP Google: the Google OpenID OP Yahoo: the Yahoo OpenID OP OIF/SP has been configured to: Use an IdP Discovery Service Redirect the user to the bundled simple IdP Discovery Service Have the  bundled simple IdP Discovery Service enabled If the user requests access to a resource protected by the FederationScheme, the bundled simple IdP Discovery Service will prompt the user to select an IdP to perform Federation SSO with: Default SSO Identity Provider If none of the previous methods were used to indicate which IdP to be used for Federation SSO, OIF/SP will use the IdP Partner that was marked as the Default SSO Identity Provider. OAM Administration Console To indicate that a specific IdP Partner should be the Default SSO Identity Provider via the OAM Administration Console, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Open the IdP Partner Check the "Default Identity Provider Partner" box Apply WLST Command To indicate that a specific IdP Partner should be the Default SSO Identity Provider using the OIF WLST setDefaultSSOIdPPartner() command, perform the following steps 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 setDefaultSSOIdPPartner() command Specify the IdP Partner Name An example would be:setDefaultSSOIdPPartner("AcmeIdP") Exit the WLST environment:exit() In the next article, I will create a custom authentication plugin in OIF/SP that will be invoked after a Federation SSO operation and will process Assertion data.Cheers,Damien Carru

As a Service Provider, when triggering a Federation SSO operation, the main challenge sometimes lies with determining which IdP will be selected for the SSO flow, in cases where the SP has trust...

Federation Proxy in OIF / IdP

In this article, I will explain the concept of Federation Proxy and how OIF/IdP can easily be configured to become an SP and delegate authentication to another remote IdP instead of authenticating the user locally. Federation Proxy is typically used when a Federation hub acts as: An IdP for SP Partners, where the IdP aggregates Federation trust between those SPs and itself An SP with remote IdP Partners This approach has the advantage of: Reducing trust management overhead: Each new IdP Partner added to the Federation hub will be automatically available to all the SP partners integrated with the Federation hub Each new SP Partner added to the Federation hub won't need to be defined at the IdP Partners     Providing a layered Federation trust model, where the Federation hub hides the Federation deployment to the IdP Partners Enjoy the reading! Direct Trust Model In this model, the various Federation servers trust each other directly and there are no intermediate entities acting as proxy. This model has the advantage of reducing the complexity of the Federation flows, because only two servers are involved with the SSO operation, but sometimes it has the drawback to create a huge management overhead that partners might not agree to. Let's take an example of a global company called ACME Corp (how original!), which has offices in the whole world. The structure of the company is made of three top organizations representing a different region of the globe, and each organization is in charge of its security domain: North & South American European Asia-Africa-Pacific Each organization has its own security domain, which means: A set of resources An SSO server A Federation server The entities of one organization are independent of the ones from another organization. As such, being authenticated in one domain will not grant you access to resources of another domain until authentication has been performed in that other domain. Now, let's say that ACME Corp wants to have Federation agreement in place with some Service Providers, some of which being suppliers, others being services purchased by ACME Corp, such as a Conference Call service, as well as a Webex service. In order to establish Federation between the various ACME Corp organizations and the SPs, each organization's Federation server will need to establish trust with each remote SP: The number of trust establishment will be high The SP Partners might refuse to this kind of trust establishment, given the high number of Federation agreements involved for a single customer This diagram represents all the agreements that would need to be put in place: This approach is typically avoided, because it publishes to the partner the internal complexity of ACME Corp's infrastructure. Federation SSO and SAML were defined to allow two distinct security domains to perform cross domain SSO in a way that one partner would not need to know about the security implementation and deployment of the other partner. In this case, it becomes obvious that this promise is broken and that the complexity of ACME Corp's security choices is impacting the SP partners. Brokered Trust Model In this model, there is the concept of Federation Proxy where some entities will be used to act as proxies/SPs to perform Federation SSO operations on behalf of other SPs. If we take our example of ACME Corp again, the correct approach to implement Federation SSO with other SP Partners is via a Brokered Trust model or Federation Proxy, where: A new server will be installed in ACME Corp acting as a Federation hub The Federation Hub will act as a Service Provider to the internal IdPs of ACME Corp The Federation Hub will act as an IdP to the external SPs (suppliers, conference call and webex) During a Federation SSO operation, instead of challenging the user directly, the hub will act as an SP and trigger a Federation SSO operation with a remote internal IdP This approach is more in line with the Federation/SAML philosophy, where the external partners are unaware of the security infrastructure and components of ACME Corp, and only interact with a single IdP. This solution also solves the high management overhead where the number of agreements was particularly high and was making any updates to the agreement a lengthy process. With this approach: Federation agreements are between the hub and internal IdPs, and between the hub and external SPs Adding an internal IdP will be invisible to the external SPs Adding an external SP will be invisible to the internal IdPs Updating the Federation agreement (for example for key rollover) will be a one-time operation as opposed to be repeated multiple times This diagram represents the Federation agreements required in a Brokered Trust (or Federation Proxy) model: Federation Proxy in OIF The goal in a Federation Proxy flow is to turn the IdP into an SP so that upon receiving an SSO request from a first remote SP, instead of challenging the user locally, the IdP will become an SP and trigger a new Federation SSO operation with a second remote IdP. Upon the successful completion of the second Federation SSO operation, the proxying IdP will have identified the user and will be able to create an SSO response for the original SP. OIF supports the Federation Proxy flow for all protocols: SAML 2.0, SAML 1.1 and OpenID 2.0 Protocol between original SP and OIF/IdP is the same as the one used between OIF/SP and the second remote IdP Protocol between original SP and OIF/IdP is different then the one used between OIF/SP and the second remote IdP So it would be possible for an SP to do Federation SSO with OIF/IdP via SAML 1.1, and OIF/IdP would become an SP and do Federation SSO with a second remote IdP via SAML 2.0. The original SP would not need to know the protocol used between OIF/SP and the second IdP, or even that a second Federation SSO operation took place. In a Federation Proxy flow, OIF/IdP can be configured to "forward" the Federation Authentication Method specified in the second Federation SSO to the original SP. Configuring OIF for Federation Proxy As discussed in a previous article, OIF/IdP leverages OAM for user authentication: each time a Federation SSO operation takes place, OIF/IdP will invoke OAM by specifying an Authentication Scheme, to ensure that the user is adequately authenticated, and challenge him/her if necessary. As you know, OAM defines specific schemes which are tied to OIF/SP: if a non authenticated user requests access to a resource protected by a FederationScheme (or scheme using an Authentication Module similar to the FederationPlugin), OAM will invoke OIF/SP which will trigger a Federation SSO operation with a remote IdP. So to have OIF/IdP do a Federation Proxy flow, instead of having OIF/IdP invoking OAM with a local Authentication Scheme, you will need to have OIF/IdP invoke OAM with a FederationScheme. From there: OAM will invoke OIF/SP and that will trigger a new Federation SSO flow with a second remote IdP The second remote IdP will authenticate the user if needed, issue an SSO response OIF/SP will validate the SSO response, create an OAM session OAM will redirect the user to OIF/IdP OIF/IdP will create an SSO response and redirect the user to the original SP with that response WLST Command To configure OIF/IdP to use Federation SSO to authenticate a user instead of a local authentication mechanism, execute the one of the following commands: setIdPDefaultScheme() to set the global default scheme to be a Federation Scheme setSPPartnerProfileDefaultScheme() to set the default scheme on an SP Partner Profile setSPPartnerDefaultScheme() to set the default scheme on an SP Partner See the article on Authentication in OIF/IdP for more information on how to configure OIF for authentication. In my example, I will configure OIF/IdP globally to use Federation SSO as the default authentication mechanism: 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 setIdPDefaultScheme() command:setIdPDefaultScheme("FederationScheme") Exit the WLST environment:exit() With this change, FederationScheme will be used to authenticate users. Other Federation Schemes can be used to authenticate the user, with OIF being configured either at the global level (all users from all SPs will be authenticated using that Federation Scheme) or at an SP Partner level (all users performing Federation SSO with that specific SP will be authenticated using that Federation Scheme). Remember that you can create a Federation Scheme for a specific IdP, either via the OIF WLST createAuthnSchemeAndModule command, or via the Edit IdP Partner section in the OAM Administration Console. Determining the Second IdP to be used When a Federation Scheme is used for authentication in OAM, OIF/SP will need to determine which IdP to use for the Federation SSO operation: If the scheme was one that was created from an IdP Partner entry, then it will indicate to OIF/SP to perform Federation SSO with that IdPIf the scheme is FederationScheme, then OIF/SP will first evaluate if it is configured to use an IdP Discovery ServiceIf it is configured for an IdP Discovery Service, OIF/SP will redirect the user to that service to select an IdPOtherwise, OIF/SP will use the Default SSO IdPTo set an IdP Partner as the Default SSO IdP: Either go to the IdP Partner in the OAM Administration Console and check the "Default Identity Provider Partner" boxOr use the OIF WLST setDefaultSSOIdPPartner() command by specifying the IdP Partner name Proxying Federation Authentication Methods As I explained in a previous article, when OIF/IdP constructs an Assertion, it will map the local OAM scheme used to authenticate the user to a Federation Authentication Method. In case of a Federation SSO Proxy flow, that would mean that a FederationScheme would be mapped to a Federation Authentication Method. For example, if the scheme needs to be mapped to urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport for SAML 2.0, the administrator would use a command similar to: To create the mapping at an SP Partner Profile level:addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ", "FederationScheme")To create the mapping at an SP Partner level:addSPPartnerAuthnMethod("AcmeSP", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ", "FederationScheme") In some cases, it might be preferable to forward the Federation Authentication Method received from the second IdP instead of mapping locally the Federation Scheme to a Federation Authentication Method. To configure OIF/IdP to forward the Federation Authentication Methods in a Federation SSO Proxy flow, use the useProxiedFedAuthnMethod() command: Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the useProxiedFedAuthnMethod() command:useProxiedFedAuthnMethod(enabled="true/false", authnSchemeToAdd="SCHEME", authnSchemeToRemove="SCHEME")The enabled parameter indicates whether or not OIF/IdP should be configured to forward the Federation Authentication Methods in a Federation SSO Proxy flowThe authnSchemeToAdd parameter indicates which OAM Authentication Scheme is a Federation Scheme: this will allow OIF/IdP to determine whether or not to use the cached Federation Authentication Method based on the authentication scheme of the user's sessionThe authnSchemeToRemove parameter removes an OAM Authentication Scheme from the list of schemes marked as Federation Schemes for which OIF/IdP should use the proxied Federation Authentication MethodAn example would be:useProxiedFedAuthnMethod(enabled="true", authnSchemeToAdd="FederationScheme")Exit the WLST environment:exit() In the next article, I will explain in details how OIF/SP can be configured to determine the IdP to be used for a Federation SSO operation.Cheers,Damien Carru

In this article, I will explain the concept of Federation Proxy and how OIF/IdP can easily be configured to become an SP and delegate authentication to another remote IdP instead of authenticating the...

DCC HTTP Reverse Proxy with OAM/OIF

Today I will discuss about the Detached Credential Collector (DCC) HTTP Reverse Proxy feature that has been introduced in the 11.1.2.2.0 release. In a deployment where this feature is enabled, a WebGate SSO Agent: Becomes a reverse HTTP proxy for the OAM and OIF services Interacts with the user over HTTP/HTTPS Routes the incoming HTTP requests for the OAM/OIF servers to the SSO and Federation servers over the secure OAM NAP protocol. Returns to the HTTP client the response sent by OAM/OIF over the NAP protocol In this mode, all interactions between the users/clients and OAM/OIF will be done via the WebGate DCC HTTP Reverse Proxy: no users will access directly the OAM/OIF servers anymore. This new DCC HTTP Reverse Proxy capability is different from the previous DCC for HTTP-Basic/FORM based login, with the latter not working for the Federation SSO flows (IdP or SP mode). Enjoy the reading! Overview In this article, I will not include any topologies containing HTTP reverse proxies or load balancer fronting the various OAM components (the OAM server itself or the WebGate agents). I will nonetheless include a use case towards the end indicating how to use DCC HTTP Reverse Proxy in HA deployments, fronted by a load balancer. Authentication without DCC The authentication flow without DCC is the most common use case, where the user is redirected from the SSO agents protecting resources in the security domain to the OAM for challenge and authentication. A typical OAM deployment is made of the following entities: The local Security Domain An OAM runtime server responsible of User authentication Managing SSO Agents Resources SSO Agent deployed on HTTP servers, protecting resources The following diagram describes such an environment: In the test flow, I will use the LDAPScheme OOTB as the scheme to protect the resources of the local security domain. A local authentication flow using the LDAPScheme would consist of the following: User requests access to a protected resource, defined in OAM to be protected by the LDAPScheme The WebGate SSO agent intercepts the HTTP request, determines that the user needs to be authenticated and redirects the user to the OAM server for authentication User accesses the OAM server; the server initiates an authentication flow using the LDAPScheme and displays the login page Once the user enters its credentials and clicks the login button the following will occur: The OAM server validates the credentials, creates a session for the user, sets a cookie in the user's browser and redirects the user to the protected resource The user requests access to the resource. This time the WebGate SSO Agent will detect that the user is authenticated and will grant access to the resource DCC for HTTP-Basic/FORM based loginDCC for HTTP-Basic/FORM based login was introduced in previous releases of OAM 11g, and it provides a way for an administrator to designate a WebGate SSO Agent as the entity which will: Challenge the user for authentication Collect the user's credentials Send them to OAM via the secured OAM NAP protocol for validation Redirect the user to the resource once authentication has been successful In this mode, the DCC WebGate: Is only used for authentication for HTTP Basic Authentication challenges FORM based authentication Is not used for accessing other OAM services Is only invoked as a credential collector when the scheme protecting the resources is configured to redirect the user to the DCC WebGate Cannot be used in conjunction with OIF as an IdP or SP, or with authentication schemes not based on HTTP Basic Authentication or FORM based authentication In the test flow, I will use the DCCLDAPScheme that is based on the LDAPScheme OOTB, but with the Challenge URL updated to reference the DCC WebGate. This scheme is used to protect the resources of the local security domain. A local authentication flow using that custom DCCLDAPScheme would consist of the following: User requests access to a protected resource, defined in OAM to be protected by the DCCLDAPScheme  The WebGate SSO agent intercepts the HTTP request, determines that the user needs to be authenticated and redirects the user to the DCC WebGate's login page for authentication User accesses the DCC WebGate's login page and provides credentials The DCC WebGate interacts directly with the OAM server other the OAM NAP protocol to validate the credentials and to create a session for the user. The DCC WebGate then redirects the user to the protected resource The user requests access to the resource. This time the WebGate SSO Agent will detect that the user is authenticated and will grant access to the resource DCC HTTP Reverse Proxy DCC HTTP Reverse Proxy was introduced in the 11.1.2.2.0 release of OAM/OIF and allows the administrator to configure a WebGate SSO Agent to act as the public endpoint for the OAM and OIF server: The user will be redirected to the DCC WebGate for any authentication operation, without requiring the schemes to be updated to reference the WebGate SSO Agent All OAM services will be accessed via the DCC WebGate Login Logout All OIF services will be accessed via the DCC WebGate Metadata retrieval (/oamfed/idp/metadata or /oamfed/sp/metadata) IdP services IdP Initiated SSO IdP Federation Protocol Endpoints SP services SP Initiated SSO SP Federation Protocol Endpoints Test SP ... The OAM and OIF servers won't be accessed directly anymore The WebGate SSO Agent will receive the incoming HTTP Request, package it and send it to OAM/OIF via the secured OAM NAP protocol; OAM/OIF will process the request and send an HTTP response to the DCC WebGate which will return the HTTP response to the client Basically, the DCC WebGate becomes the public endpoint for OAM and OIF and acts as an HTTP Reverse Proxy, over the OAM NAP protocol. In this test, after OAM and the WebGate have been configured for DCC HTTP Reverse Proxy, I will use the LDAPScheme OOTB as the scheme to protect the resources of the local security domain (the scheme won't have been changed) Note: any authentication scheme with a Challenge URL containing a relative path can be used in this DCC mode, such as the FederationScheme. Also, IdP feature is compatible with that DCC mode A local authentication flow using the LDAPScheme would consist of the following: User requests access to a protected resource, defined in OAM to be protected by the LDAPScheme The WebGate SSO agent intercepts the HTTP request, determines that the user needs to be authenticated and redirects the user to the DCC WebGate for authentication User accesses the DCC WebGate and forwards the request to the OAM server; the server initiates an authentication flow using the LDAPScheme, returns a login page to be displayed to the DCC WebGate, and the DCC WebGate displays the login page to the user Once the user enters its credentials and clicks the login button the following will occur: The DCC WebGate sends the HTTP request containing the credentials to the OAM server which validates them, creates a session for the user, creates a cookie and returns an HTTP Response with the cookie and a redirection command to the DCC WebGate; the DCC WebGate sets the cookie in the user's browser and redirects the user to the protected resource The user requests access to the resource. This time the WebGate SSO Agent will detect that the user is authenticated and will grant access to the resource Setting Up DCC HTTP Reverse Proxy  Initial SetupThe steps required to configure an OAM deployment for DCC HTTP Reverse Proxy are divided into: Configure the 11.1.2.2.0+ WebGate SSO Agent for DCC HTTP Reverse Proxy Update the Authentication Policies for the OAM and OIF services Update the OAM configuration to specify the DCC WebGate as the new public endpoint for OAM/OIF To configure a specific WebGate SSO Agent as a DCC WebGate, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> SSO Agents Search for the WebGate entry you already registered Click and open the WebGate entry Check the Allow Credentials Collector Operations box In the User Defined Parameter box, add the following line: TunneledUrls=/oam,/oamfed Click Apply To update the Authentication Policies for the OAM and OIF services, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domains Search for the Application Domain related to the DCC WebGate Open the Application Domain  Click on the Resources tab Configure the following resource as Public resources, by marking the resources as Unprotected and setting a public authentication policy and a public authorization policy: /oamfed/.../* /oam/.../* /.../* Apply To update the OAM configuration to specify the DCC WebGate as the new public endpoint for OAM/OIF Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Access Manager Settings In the OAM Server Host, enter the hostname that will be used to access the DCC WebGate via the browser In the OAM Server Port, enter the port that will be used to access the DCC WebGate via the browser In the OAM Server Protocol, enter the http protocol that will be used to access the DCC WebGate via the browser Once done, those three fields should reference the DCC WebGate HTTP/HTTPS endpoint Apply Once those three configuration changes are done, OAM and OIF will be configured to use the DCC WebGate as the HTTP Reverse Proxy over the NAP protocol.  As a test, if Federation has been enabled in the OAM Administration Console -> Configuration -> Available Services section, you can access the OIF metadata via the DCC WebGate URL: http(s)://dcc-webgate-host:dcc-webgate-port/oamfed/idp/metadata, and it should display the SAML 2.0 Metadata for OIF. In my setup, the Metadata showed up without having to restart any services, and the URLs of the Federation services reference the DCC WebGate location, not the OAM/OIF server anymore.  Note: if the Federation ProviderID needs to be updated, you can do so via the OAM Administration Console -> Configuration -> Federation, and the change will be reflected in the Metadata's entityID attribute An example of the metadata would be (entityID is derived from the OAM Administration Console -> Configuration -> Federation section): <md:EntityDescriptor entityID="http://oam.acme.com/oam/fed" ...>  ...  <md:IDPSSODescriptor>    ...    <md:ArtifactResolutionService ... Location="http://dcc-webgate.acme.com:7777/oamfed/idp/soap"/>    <md:SingleLogoutService ... Location="http://dcc-webgate.acme.com:7777/oamfed/idp/samlv20"/>    <md:SingleSignOnService ... Location="http://dcc-webgate.acme.com:7777/oamfed/idp/samlv20"/>    ...  </md:IDPSSODescriptor>  ...</md:EntityDescriptor> Local AuthenticationIn my test deployment, I have the following deployed: OAM server running on oam.acme.com on port 14100 OHS1 with WebGate1 as an SSO Agent on oam.acme.com on port 23777 A resource on that OHS server is /cgi-bin/printenv This resource is protected by a policy using the LDAPScheme OHS2 with WebGate2 acting as the DCC HTTP Reverse Proxy on dcc-webgate.acme.com on port 7777 The LDAPScheme is the OOTB one and has not been modified, specifically the Challenge URL parameter does not reference WebGate DCC: Prior to configuring OAM, OIF and the WebGate2 for DCC HTTP Reverse Proxy, requesting access to the /cgi-bin/printenv protected resource on OHS1 was resulting in WebGate1 intercepting the request and redirecting the browser to the OAM server for authentication: Upon entering the correct credentials, OAM was validating the username/password and redirecting the browser to the protected resource. After having configured OAM, OIF and the WebGate2 for DCC HTTP Reverse Proxy, requesting access to the /cgi-bin/printenv protected resource on OHS1 now results in WebGate1 intercepting the request and redirecting the browser to the DCC WebGate for authentication which will forward the HTTP request over the NAP protocol to the OAM server which will send back to the DCC WebGate a page to be displayed: Upon entering the correct credentials, the following occurs: DCC WebGate will package the HTTP Request containing the credentials and send it over NAP to the OAM server OAM server validates the username/password, creates an OAM session, constructs an HTTP Response made of a cookie being set and a 302 redirect referencing the protected resource, packages it and sends it to DCC WebGate DCC WebGate receives the response from the OAM and returns it to the user's browser The user's browser is redirected to the protected resource and granted access OIF as an SPThis mode slightly differs from the local authentication use case. The only differences are: OIF has been enabled A Federation agreement has been put into place between OIF/SP and a remote IdP, configured in OIF/SP to be the Default SSO Identity Provider Instead of using the LDAPScheme to protect the resource, the FederationScheme is used No special configuration is necessary to use the FederationScheme with the DCC HTTP Reverse Proxy! The FederationScheme is the OOTB one and has not been modified, specifically the Challenge URL parameter does not reference WebGate DCC: When the protected resource is requested, the following will occur: User requests access to a protected resource, defined in OAM to be protected by the FederationScheme The WebGate SSO agent intercepts the HTTP request, determines that the user needs to be authenticated and redirects the user to the DCC WebGate for authentication User accesses the DCC WebGate, which packages the HTTP requests and send it over NAP to the OAM server; the server determines that the user needs to be challenged via the FederationScheme, and the OIF/SP module is invoked,  OIF/SP creates a SAML Request and constructs a 302 redirect URL with the SAML message; OAM packages the data and sends the response back to the DCC WebGate which returns the HTTP response to the user's browser The user's browser is redirected to the IdP with the SAML Request Once the user enters its credentials at the IdP, the following occurs: The IdP will create a SAML Assertion and redirect the user's browser with the SAML message to the DCC WebGate (which is the Federation endpoint for OIF, published in the SAML 2.0 Metadata) The user's browser presents the SAML Assertion to the DCC WebGate, which packages the HTTP requests and send it over NAP to the OAM server, which in turn invokes the OIF/SP module to process the SAML Assertion OIF/SP validates the SAML Assertion, OAM creates a user session, builds a 302 redirect to the protected resource and sends the response back to the DCC WebGate which returns the HTTP response to the user's browser The user is redirected to the protected resource; WebGate SSO Agent grants access OIF as an IdPIn this use case, OIF acts as an Identity Provider and the DCC WebGate is the public endpoint for the OIF/IdP. In this setup: OIF has been enabled A Federation agreement has been put into place between OIF/IdP and a remote SP The OIF/IdP has been configured to use LDAPScheme as the default scheme to authenticate users. The LDAPScheme is the OOTB one and has not been modified, specifically the Challenge URL parameter does not reference WebGate DCC (see the snapshot in the previous section if needed) No special configuration is necessary to use the OIF/IdP with the DCC HTTP Reverse Proxy! When a user initiates a Federation SSO from the remote SP, the following will occur: User starts a Federation SSO operation at the remote SP The remote SP creates a SAML Request, and redirects the user to the OIF/IdP SAML 2.0 endpoint with the SAML Request: this endpoint is the DCC WebGate HTTP Reverse Proxy, as published in the OIF/IdP SAML 2.0 Metadata  The User accesses the OIF/IdP public SAML 2.0 endpoint at the DCC WebGate with the SAML Request; the DCC WebGate packages the HTTP Request and the SAML message and forwards it to the OIF/IdP server over the OAM NAP protocol The OIF/IdP server processes the SAML Request, determines that the user needs to be authenticated via the LDAPScheme, invokes internally OAM for authentication, which in turn return to the DCC WebGate the login page to be displayed; the DCC WebGate decodes the response from OAM sent over NAP, and returns the HTTP response to the user's browser After the display of the login page, the following will occur: The user enters its credentials and click the login button; DCC WebGate collects the incoming data, packages it and sends it to the OAM server over NAP OAM validates the credentials, creates a session for the user, and returns internally the user's identity to OIF/IdP; the Federation server creates a SAML Assertion, and builds a response containing the Assertion, packages it and returns it to the DCC WebGate, which in turn decodes the data, and sends the HTTP Response with the SAML Assertion to the user's browser The user's browser posts the SAML Response to the SP which successfully validates the Assertion DCC HTTP Reverse Proxy and HA In an HA deployment, the steps required to configure the various components (Load balancer, OAM...) still apply when the DCC HTTP Reverse Proxy feature is used.  Let's take as an example the following deployment (other kinds of HA topologies would use a similar approach): The sample cluster is made of several OAM runtime servers Each server is fronted by a DCC HTTP Reverse Proxy WebGate deployed on an OHS instance A load balancer fronts the various DCC HTTP Reverse Proxy WebGate agents and routes the traffic between them The topology in this example would look like: The steps required in this example would be based on: The steps to set up DCC HTTP Reverse Proxy The OAM public endpoint configured in the OAM Administration Console -> Configuration -> Access Manager Settings section would reference the Load Balancer, and not any of the DCC WebGate Agents The Load Balancer would route the /oam and /oamfed requests to the DCC WebGate agents Cheers,Damien Carru

Today I will discuss about the Detached Credential Collector (DCC) HTTP Reverse Proxy feature that has been introduced in the 11.1.2.2.0 release. In a deployment where this feature is enabled, a...

Crypto Settings in OIF

In this article, I will cover the various crypto configuration properties in OIF that are used to affect the Federation SSO exchanges, including: Hashing algorithm used for signatures SHA-1 SHA-256 Which outgoing SAML messages will be signed Which incoming SAML messages will require to be signed Whether or not to include the X.509 signing certificate in the outgoing signed XML message Whether or not to encrypt SAML 2.0 messages: Assertion NameID Attribute Enjoy the reading! Hashing Algorithms OIF supports the consumption and issuance of SAML messages signed with Either the SHA-1 hashing algorithm Or the SHA-256 hashing algorithm By default, OIF uses SHA-1 when signing outgoing messages. Messages are signed differently, based on the binding being used: XML Digital signatures when HTTP-POST or Artifact bindings are used Query signatures when the HTTP-Redirect binding is used SHA-1 An example of a signed AuthnRequest message sent via the HTTP-Redirect binding would be: https://acme.com/idp/saml20?SAMLRequest=hVPLbtswEPwVgT1LpB6tY8JyoNZ1q9ZujVgJ3N4Yio5ZSKTMpaz470v5ESQB4gA8LWZ2ZnaXo%2BvHuvJ2woDUKkVhQJAnFNelVA8pui2m%2FhXywDJVskorkaK9AHQ9HgGrq4Zmrd2oG7FtBVjPNVJAS5COuLG2oRh3XRd0caDNA44IIZgMsUP1kA%2FohHdib8BDTJIe7hBP6F42Ra1RVDOQQBWrBVDL6TKbz2gUEMoAhLEuzHNKc5nTGG0119WZ8viRkHcZa1m5IrPWyPvWCrpypKcGIN8MtZrPlnwjauZL1Q%2BWC%2BQtTgY%2BS3Uc%2FCXt%2ByMI6PeiWPiL38sCefkkRbL0V7ff2m0mok1e%2BoP4x66bbdlPGFgYtpP5n09f%2Fbn%2Fb9CqKfLuzhuP%2Bo3nAK3ID3asK5Ew8Yl7cREmNLmiJP6LvInbsVTMHlinbKzkhDRiG7TgAjJeiYDrmg6S4RCvRYll2eB%2B%2FruIoOPN0IOU8aba1MxeDtpXXKj1AeoOxUq7R%2BMX0py%2Fko5iQiKsWd3rj%2FAzyfPN%2FnJd88lCV5Lv37URBuFrGzWTVVaWRgAgL6sq3X0xgln3NaxpBcLjo%2BrLzzH%2BDw%3D%3D&RelayState=id-AkgTE5PMRAZTaKRcZHT-2rIse-oPhCxyI00Xycbf&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=rjZFsFuaFKv77JbspdDwT2wGV366iL3zvWc%2B1aybu%2FW%2BpFwLOfTJBtVsKfwJre1nGCU5SEvFD%2FBBURkxOG1KhR3k%2FrOw%2Bj7g7RlHfSaHKaAO3p6aAGQYPCpz%2Fd0%2BKArDAL%2FDNoH46G6Pnf7VWSb6a2COUiTV6118KaPbexrnJtE%3D An example of a SAML 2.0 Assertion sent via the HTTP-POST binding would be: <samlp:Response ...<samlp:Response ...>  <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">...</saml:Issuer>  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>  <saml:Assertion ID="id-BgLUimKUWYyS3JQbf2geeP9EwS-eGKxOPTuPvxgJ" ...>    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">...</saml:Issuer>    <dsig:Signature>      <dsig:SignedInfo>        <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>        <dsig:Reference URI="#id-BgLUimKUWYyS3JQbf2geeP9EwS-eGKxOPTuPvxgJ">          <dsig:Transforms>            <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>            <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>          </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>          <dsig:DigestValue>uS85cIFf4z9KcHH/z60fNRPLoyo=</dsig:DigestValue>        </dsig:Reference>      </dsig:SignedInfo>      <dsig:SignatureValue>NiTyPtOEjyG...SpVjbhKxY=</dsig:SignatureValue>    </dsig:Signature>    <saml:Subject>      ...    </saml:Subject>    <saml:Conditions ...>      ...    </saml:Conditions>    <saml:AuthnStatement ...>      ...    </saml:AuthnStatement>  </saml:Assertion></samlp:Response> SHA-256 An example of a signed AuthnRequest message sent via the HTTP-Redirect binding would be: https://acme.com/idp/saml20?SAMLRequest=hVNdb9owFP0rkfec%2BCbAVixClY2hIdGWDui6vhnbFEuOndoOKfv1c%2Fio2kqlkp%2BuzrnnnHuvB5fPpYq2wjppdI7SBFAkNDNc6sccLRfj%2BAJFzlPNqTJa5GgnHLocDhwtVUWK2m%2F0b%2FFUC%2Bej0Eg7wp0MxI33FcG4aZqk6STGPuIMADD0cUC1kC%2FoiA9iH8BTDN0WHhAv6FY2R7XVxFAnHdG0FI54RubF1ZRkCRDqnLA%2BhHlNqc5zKmu8YUadKM89gE8Za6lCkXpv5ar2gtwH0ksDJz8MdX81nbONKGksdTtYJlA0Oxr4LvVh8Oe0VweQI78Wi1k8u5kvUDQZ5Ujy%2BC80RSY7d9BQc7tKR5kxD0td9LYXN9M%2FFR%2F%2FFLDswb9bFN2dNp61G584V4vJ3o4PJUi7MYTXWaRd0vtKoP%2BAolHYsdTU71nHbJQzgEo8JbULASlTImGmJN%2B6%2FT5eC44lr3A7%2F20G6HAzZC9lo7GxJfXng7aVEGq9h4ZD8dLv0PCNNGPvpLMOQIYNLVv9AX4lebrZ69B1MpoZJdnuUxtpkr63UVKpCs6tcA5FhVKm%2BWEF9eFreFsLhIcH1befY%2Fgf&RelayState=id-BiQreMi9cMY3oFI9PKMNKtuOjpuFS2PrW4R8KKvd&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=PvyMUD%2FKXnCc0drlN1pvoK171znJkajEHLgtzE4I7YFQIvP4wp3M%2FV7y08x0Qkv0jwo9K4VBG%2BQUBFtXr41ZDp%2BHOb7GlmaY973n7X2UDlbUbVlrJX%2FqS1GyyNY6MSMcO5K0J7VJcQXf8CvGEcVHr%2FZhPjihnAO2vi%2Bej3fbfgo%3D An example of a SAML 2.0 Assertion sent via the HTTP-POST binding would be: <samlp:Response ...<samlp:Response ...>  <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">...</saml:Issuer>  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>  <saml:Assertion ID="id-5B4KZ-PeUzikxtC-Cr9g6uFQ-muwj3ZmC4PUW4wT" ...>    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">...</saml:Issuer>    <dsig:Signature>      <dsig:SignedInfo>        <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>        <dsig:Reference URI="#id-5B4KZ-PeUzikxtC-Cr9g6uFQ-muwj3ZmC4PUW4wT">          <dsig:Transforms>            <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>            <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>          </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>          <dsig:DigestValue>Ppx/...L9ooHtsvgxvI=</dsig:DigestValue>        </dsig:Reference>      </dsig:SignedInfo>      <dsig:SignatureValue>G6yppQXy...SzHz2oa+zA=</dsig:SignatureValue>    </dsig:Signature>    <saml:Subject>      ...    </saml:Subject>    <saml:Conditions ...>      ...    </saml:Conditions>    <saml:AuthnStatement ...>      ...    </saml:AuthnStatement>  </saml:Assertion></samlp:Response> WLST Command OIF can be configured to use SHA-1 or SHA-256 in SAML signatures: At a Partner level At a Partner Profile level, where all partners referencing this profile will be affected, unless they were configured at a partner level for SHA-1/SHA-256 signatures The OIF WLST configureFedDigitalSignature() command is used to configure how OIF should compute a signature: 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 configureFedDigitalSignature() command:configureFedDigitalSignature(partner="", partnerProfile="", partnerType="", default="false", algorithm="SHA-256", displayOnly="false", delete="false") The following parameters can be set: partner would be used to configure a specific partner partnerProfile would be used to configure a specific partner profile partnerType would indicate the type of partner/partner profile (idp or sp) algorithm indicates which hashing algorithm to use (SHA-1 or SHA-256) displayOnly indicates whether or not the command should display the setting on this partner/partner profile instead of setting it. If set to true, this command will not modify the configuration (true or false) delete indicates whether or not the command should delete the setting on this partner/partner profile instead of setting it. If set to true, this command will delete the configuration and the parent configuration (partner profile or global) will be used (true or false) An example would be:configureFedDigitalSignature(partner="AcmeIdP", partnerType="idp", algorithm="SHA-256") Exit the WLST environment:exit() Signing Outgoing Messages OOTB Configuration Below are the OOTB boolean settings that indicate when OIF needs to sign outgoing SAML messages (if true, OIF will sign the outgoing messages): Global level saml20sendsignedauthnrequest: SAML 2.0 AuthnRequest (true) SAML 1.1 IdP Partner Profile sendsignedrequestsoap: SAML 1.1 Request via the Artifact/SOAP binding (true) SAML 1.1 SP Partner Profile sendsignedassertion: SAML 1.1 Assertion (true) sendsignedresponseassertionpost: SAML 1.1 Response containing an Assertion over the HTTP-POST binding (false) sendsignedresponseassertionsoap: SAML 1.1 Response containing an Assertion over the Artifact/SOAP binding (false) sendsignedresponsesoap: SAML 1.1 Response not containing an Assertion over the Artifact/SOAP binding  (true) SAML 2.0 IdP Partner Profile sendsignedrequestpost: SAML 2.0 Request over the HTTP-POST binding (true) sendsignedrequestquery: SAML 2.0 Request over the HTTP-Redirect binding (true) sendsignedrequestsoap: SAML 2.0 Request over the Artifact/SOAP binding (true) sendsignedresponsepost: SAML 2.0 Response not containing an Assertion over the HTTP-POST binding (true) sendsignedresponsequery: SAML 2.0 Response not containing an Assertion over the HTTP-Redirect binding (true) sendsignedresponsesoap: SAML 2.0 Response not containing an Assertion over the Artifact/SOAP binding (true) SAML 2.0 SP Partner Profile sendsignedassertion: SAML 2.0 Assertion (true) sendsignedrequestpost: SAML 2.0 Request over the HTTP-POST binding (true) sendsignedrequestquery: SAML 2.0 Request over the HTTP-Redirect binding (true) sendsignedrequestsoap: SAML 2.0 Request over the Artifact/SOAP binding (true) sendsignedresponseassertionpost: SAML 2.0 Response containing an Assertion over the HTTP-POST binding (false) sendsignedresponseassertionsoap: SAML 2.0 Response containing an Assertion over the Artifact/SOAP binding (false) sendsignedresponsepost: SAML 2.0 Response not containing an Assertion over the HTTP-POST binding (true) sendsignedresponsequery: SAML 2.0 Response not containing an Assertion over the HTTP-Redirect binding (true) sendsignedresponsesoap: SAML 2.0 Response not containing an Assertion over the Artifact/SOAP binding (true) Configuration I will assume that you are already in the WLST environment and connected using: 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() SAML 2.0 AuthnRequest To configure OIF to sign an outgoing SAML 2.0 AuthnRequest, execute one of the following commands:     To configure at a global level, execute:putBooleanProperty("/spglobal/saml20sendsignedauthnrequest", "true/false") Set the value to true to have OIF sign the outgoing AuthnRequest An example would beputBooleanProperty("/spglobal/saml20sendsignedauthnrequest", "true") To configure at a SAML 2.0 IdP Partner Profile level, execute:putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/sendsignedauthnrequest", "true/false") Replace PARTNER_PROFILE by a SAML 2.0 IdP Partner Profile name Set the value to true to have OIF sign the outgoing AuthnRequest An example would beputBooleanProperty("/fedpartnerprofiles/saml20-idp-partner-profile/sendsignedauthnrequest", "true") To configure at a SAML 2.0 IdP Partner level, execute:updatePartnerProperty("PARTNER", "idp", "sendsignedauthnrequest", "true/false", "boolean") Replace PARTNER by a SAML 2.0 IdP Partner name Set the value to true to have OIF sign the outgoing AuthnRequest An example would beupdatePartnerProperty("AcmeIdP", "idp", "sendsignedauthnrequest", "false", "boolean") Other Settings To configure the properties defined at the SP/IdP Partner Profiles above, execute one of the following commands: To configure at a Partner Profile level, execute:putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/PROPERTY_NAME", "true/false") Replace PARTNER_PROFILE by a Partner Profile name Replace PROPERTY_NAME by the name of the property to set Set the value to true or false An example would beputBooleanProperty("/fedpartnerprofiles/saml20-idp-partner-profile/sendsignedrequestquery", "true") To configure at a Partner level, execute:updatePartnerProperty("PARTNER", "PARTNER_TYPE", "PROPERTY_NAME", "true/false", "boolean") Replace PARTNER by a Partner name Replace PARTNER_TYPE by the type of the specified Partner (idp or sp) Replace PROPERTY_NAME by the name of the property to set Set the value to true or false An example would beupdatePartnerProperty("AcmeSP", "sp", "sendsignedrequestquery", "true", "boolean") Metadata Changing the saml20sendsignedauthnrequest property at a global level would change the SAML 2.0 Metadata generated by OIF, as: The AuthnRequestsSignedattribute in the SPSSODescriptor element is set based on saml20sendsignedauthnrequest A sample SAML 2.0 Metadata would show those two attributes: <md:EntityDescriptor ...>  <dsig:Signature>  ...  </dsig:Signature>  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" ...>  ...  </md:IDPSSODescriptor>  <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" ...>  </md:SPSSODescriptor></md:EntityDescriptor> Requiring Messages to be Signed OOTB Configuration Below are the OOTB boolean settings that govern when OIF needs to require incoming SAML messages to be signed (if true, OIF requires the incoming message to be signed): Global level saml20requiresignedauthnrequest: SAML 2.0 AuthnRequest (false) saml11requiresignedassertion: SAML 1.1 Assertion contained in a Response message (true) saml20requiresignedassertion: SAML 2.0 Assertion contained in a Response message (true) SAML 1.1 IdP Partner Profile requiresignedresponseassertionpost: SAML 1.1 Response via the HTTP-POST binding (false) requiresignedresponseassertionsoap: SAML 1.1 Response via the Artifact/SOAP binding (false) SAML 1.1 SP Partner Profile requiresignedrequestsoap: SAML 1.1 Request via the Artifact/SOAP binding (false) SAML 2.0 IdP Partner Profile requiresignedrequestpost: SAML 2.0 Request over the HTTP-POST binding (false) requiresignedrequestquery: SAML 2.0 Request over the HTTP-Redirect binding (false) requiresignedrequestsoap: SAML 2.0 Request over the Artifact/SOAP binding (false) requiresignedresponseassertionpost: SAML 2.0 Response containing an Assertion over the HTTP-POST binding (false) requiresignedresponseassertionsoap: SAML 2.0 Response containing an Assertion over the Artifact/SOAP binding (false) requiresignedresponsepost: SAML 2.0 Response not containing an Assertion over the HTTP-POST binding (false) requiresignedresponsequery: SAML 2.0 Response not containing an Assertion over the HTTP-Redirect binding (false) requiresignedresponsesoap: SAML 2.0 Response not containing an Assertion over the Artifact/SOAP binding (false) SAML 2.0 SP Partner Profile requiresignedrequestpost: SAML 2.0 Request over the HTTP-POST binding (false) requiresignedrequestquery: SAML 2.0 Request over the HTTP-Redirect binding (false) requiresignedrequestsoap: SAML 2.0 Request over the Artifact/SOAP binding (false) requiresignedresponsepost: SAML 2.0 Response not containing an Assertion over the HTTP-POST binding (false) requiresignedresponsequery: SAML 2.0 Response not containing an Assertion over the HTTP-Redirect binding (false) requiresignedresponsesoap: SAML 2.0 Response not containing an Assertion over the Artifact/SOAP binding (false) Important Note: if an incoming message is signed, OIF will verify it and return an error if signature validation failed, even if OIF does not require that type of message to be signed. Configuration I will assume that you are already in the WLST environment and connected using: 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() SAML 2.0 AuthnRequest To configure OIF to require or not incoming AuthnRequest messages to be signed, execute one of the following commands:     To configure at a global level, execute:putBooleanProperty("/idpglobal/saml20requiresignedauthnrequest", "true/false") Set the value to true to have OIF require incoming AuthnRequest to be signed An example would beputBooleanProperty("/idpglobal/saml20requiresignedauthnrequest", "true") To configure at a SAML 2.0 SP Partner Profile level, execute:putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/requiresignedauthnrequest", "true/false") Replace PARTNER_PROFILE by a SAML 2.0 SP Partner Profile name Set the value to true to have OIF require incoming AuthnRequest to be signed An example would beputBooleanProperty("/fedpartnerprofiles/saml20-sp-partner-profile/requiresignedauthnrequest", "true") To configure at a SAML 2.0 SP Partner level, execute:updatePartnerProperty("PARTNER", "sp", "requiresignedauthnrequest", "true/false", "boolean") Replace PARTNER by a SAML 2.0 SP Partner name Set the value to true to have OIF require incoming AuthnRequest to be signed An example would beupdatePartnerProperty("AcmeSP", "sp", "requiresignedauthnrequest", "false", "boolean") SAML 1.1 Assertion contained in a Response message To configure OIF to require or not incoming SAML 1.1 Assertions to be signed, execute one of the following commands: To configure at a global level, execute:putBooleanProperty("/spglobal/saml11requiresignedassertion", "true/false") Set the value to true to have OIF require incoming SAML 1.1 Assertions to be signed An example would beputBooleanProperty("/spglobal/saml11requiresignedassertion", "true") To configure at a SAML 1.1 IdP Partner Profile level, execute:putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/requiresignedassertion", "true/false") Replace PARTNER_PROFILE by a SAML 1.1 IdP Partner Profile name Set the value to true to have OIF require incoming SAML 1.1 Assertions to be signed An example would beputBooleanProperty("/fedpartnerprofiles/saml11-idp-partner-profile/requiresignedassertion", "true") To configure at a SAML 1.1 IdP Partner level, execute:updatePartnerProperty("PARTNER", "idp", "requiresignedassertion", "true/false", "boolean") Replace PARTNER by a SAML 1.1 IdP Partner name Set the value to true to have OIF require incoming SAML 1.1 Assertions to be signed An example would beupdatePartnerProperty("AcmeSP", "sp", "requiresignedassertion", "false", "boolean") SAML 2.0 Assertion contained in a Response message To configure OIF to require or not incoming SAML 2.0 Assertions to be signed, execute one of the following commands: To configure at a global level, execute:putBooleanProperty("/spglobal/saml20requiresignedassertion", "true/false") Set the value to true to have OIF require incoming SAML 2.0 Assertions to be signed An example would beputBooleanProperty("/spglobal/saml20requiresignedassertion", "true") To configure at a SAML 2.0 IdP Partner Profile level, execute:putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/requiresignedassertion", "true/false") Replace PARTNER_PROFILE by a SAML 2.0 IdP Partner Profile name Set the value to true to have OIF require incoming SAML 2.0 Assertions to be signed An example would beputBooleanProperty("/fedpartnerprofiles/saml20-idp-partner-profile/requiresignedassertion", "true") To configure at a SAML 2.0 IdP Partner level, execute:updatePartnerProperty("PARTNER", "idp", "requiresignedassertion", "true/false", "boolean") Replace PARTNER by a SAML 2.0 IdP Partner name Set the value to true to have OIF require incoming SAML 2.0 Assertions to be signed An example would beupdatePartnerProperty("AcmeSP", "sp", "requiresignedassertion", "false", "boolean") Other Settings To configure the properties defined at the SP/IdP Partner Profiles above, execute one of the following commands: To configure at a Partner Profile level, execute:putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/PROPERTY_NAME", "true/false") Replace PARTNER_PROFILE by a Partner Profile name Replace PROPERTY_NAME by the name of the property to set Set the value to true or false An example would beputBooleanProperty("/fedpartnerprofiles/saml20-idp-partner-profile/requiresignedrequestquery", "true") To configure at a Partner level, execute:updatePartnerProperty("PARTNER", "PARTNER_TYPE", "PROPERTY_NAME", "true/false", "boolean") Replace PARTNER by a Partner name Replace PARTNER_TYPE by the type of the specified Partner (idp or sp) Replace PROPERTY_NAME by the name of the property to set Set the value to true or false An example would beupdatePartnerProperty("AcmeSP", "sp", "requiresignedrequestquery", "true", "boolean") Metadata Changing the saml20requiresignedauthnrequest or saml20requiresignedassertion properties at a global level would change the SAML 2.0 Metadata generated by OIF, as: The WantAuthnRequestsSigned attribute in the IDPSSODescriptor element is set based on saml20requiresignedauthnrequest The WantAssertionsSigned attribute in the SPSSODescriptor element is set based on saml20requiresignedassertion A sample SAML 2.0 Metadata would show those two attributes: <md:EntityDescriptor ...>  <dsig:Signature>  ...  </dsig:Signature>  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" ...>  ...  </md:IDPSSODescriptor>  <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" ...>  </md:SPSSODescriptor></md:EntityDescriptor> X.509 Certificate in Message OIF can be configured to send the X.509 signing certificate in the outgoing XML SAML message sent via the HTTP-POST or SOAP bindings. The includecertinsignature boolean property indicates whether or not the certificate will be added to the message. To configure OIF to send the X.509 signing certificate in the outgoing message, execute one of the following commands to set the includecertinsignature boolean property: To configure at a Partner Profile level, execute:putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/includecertinsignature", "true/false") Replace PARTNER_PROFILE by a Partner Profile name Set the value to true or false An example would beputBooleanProperty("/fedpartnerprofiles/saml20-sp-partner-profile/includecertinsignature", "true") To configure at a Partner level, execute:updatePartnerProperty("PARTNER", "PARTNER_TYPE", "includecertinsignature", "true/false", "boolean") Replace PARTNER by a Partner name Replace PARTNER_TYPE by the type of the specified Partner (idp or sp) Set the value to true or false An example would beupdatePartnerProperty("AcmeSP", "sp", "includecertinsignature", "true", "boolean") SAML 2.0 Encryption The SAML 2.0 protocol defines a way to encrypt various data in messages: Assertions NameIDs Attributes OIF allows an administrator to indicate which types of data should be encrypted. OOTB Configuration Below are the OOTB boolean settings that indicate when OIF needs to encrypt outgoing SAML messages (if true, OIF will encrypt the outgoing data): SAML 2.0 IdP Partner Profile sendencryptednameid: indicates if NameID contained in LogoutRequest messages should be encrypted (false) SAML 2.0 SP Partner Profile sendencryptedattribute: indicates if each attribute contained in a SAML Assertion should be encrypted (false) sendencryptednameid: indicates if NameID contained in LogoutRequest, Assertion messages should be encrypted (false) When creating a new SP Partner, the configuration for that Partner will indicate that the OIF/IdP should not encrypt the Assertion: sendencryptedassertion on the partner entry: indicates if the Assertionshould be encrypted (false) Encrypted Assertion To configure OIF/IdP to encrypt the outgoing Assertion for an SP Partner via the OAM Administration Console, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Open the SP Partner In the Advanced section, check the "Encrypt Assertion" checkbox Save To configure the SP Partner via WLST, perform the following steps: 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 updatePartnerProperty() command:updatePartnerProperty("PARTNER", "sp", "sendencryptedassertion", "true/false", "boolean") Replace PARTNER by a Partner name Set the value to true or false An example would beupdatePartnerProperty("AcmeSP", "sp", "sendencryptedassertion", "true", "boolean") Exit the WLST environment:exit() Encrypted NameID/Attributes To configure the properties, perform the following steps: 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 one of the following commands: To configure at a Partner Profile level, execute:putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/PROPERTY_NAME", "true/false") Replace PARTNER_PROFILE by a Partner Profile name Replace PROPERTY_NAME by the name of the property to set Set the value to true or false An example would beputBooleanProperty("/fedpartnerprofiles/saml20-sp-partner-profile/sendencryptedattribute", "true") To configure at a Partner level, execute:updatePartnerProperty("PARTNER", "PARTNER_TYPE", "PROPERTY_NAME", "true/false", "boolean") Replace PARTNER by a Partner name Replace PARTNER_TYPE by the type of the specified Partner (idp or sp) Replace PROPERTY_NAME by the name of the property to set Set the value to true or false An example would beupdatePartnerProperty("AcmeSP", "sp", "sendencryptedattribute", "true", "boolean") Exit the WLST environment:exit() Encryption Algorithm The encryption algorithm can be defined at the Partner level or Partner Profile level, by setting the defaultencryptionmethod string property to one of the following values: http://www.w3.org/2001/04/xmlenc#aes128-cbc for AES-128 CBC http://www.w3.org/2001/04/xmlenc#aes192-cbc for AES-192 CBC http://www.w3.org/2001/04/xmlenc#aes256-cbc for AES-256 CBC http://www.w3.org/2001/04/xmlenc#tripledes-cbc for 3DES CBC By default, that property is set to http://www.w3.org/2001/04/xmlenc#aes128-cbc (AES-128 CBC). To configure the defaultencryptionmethod property, perform the following steps: 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 one of the following commands: To configure at a Partner Profile level, execute:putStringProperty("/fedpartnerprofiles/PARTNER_PROFILE/defaultencryptionmethod", "ALGORITHM") Replace PARTNER_PROFILE by a Partner Profile name Replace ALGORITHM by one of the above algorithm values An example would beputStringProperty("/fedpartnerprofiles/saml20-sp-partner-profile/defaultencryptionmethod", "http://www.w3.org/2001/04/xmlenc#tripledes-cbc") To configure at a Partner level, execute:updatePartnerProperty("PARTNER", "PARTNER_TYPE", "defaultencryptionmethod", "ALGORITHM", "string") Replace PARTNER by a Partner name Replace PARTNER_TYPE by the type of the specified Partner (idp or sp) Replace ALGORITHM by one of the above algorithm values An example would beupdatePartnerProperty("AcmeSP", "sp", "defaultencryptionmethod", "http://www.w3.org/2001/04/xmlenc#tripledes-cbc", "string") Exit the WLST environment:exit() In the next article, I will show how to configure a WebGate SSO Agent as a HTTP Reverse Proxy for the OAM/OIF services, with the WebGate communicating with the servers over the secure OAM NAP protocol.Cheers,Damien Carru

In this article, I will cover the various crypto configuration properties in OIF that are used to affect the Federation SSO exchanges, including: Hashing algorithm used for signatures SHA-1 SHA-256 Which...

AuthnRequest Settings in OIF / SP

In this article, I will list the various OIF/SP settings that affect how an AuthnRequest message is created in OIF in a Federation SSO flow. The AuthnRequest message is used by an SP to start a Federation SSO operation and to indicate to the IdP how the operation should be executed: How the user should be challenged at the IdP Whether or not the user should be challenged at the IdP, even if a session already exists at the IdP for this user Which NameID format should be requested in the SAML Assertion Which binding (Artifact or HTTP-POST) should be requested from the IdP to send the Assertion Which profile should be used by OIF/SP to send the AuthnRequest message Enjoy the reading! Protocols The SAML 2.0, SAML 1.1 and OpenID 2.0 protocols define different message elements and rules that allow an administrator to influence the Federation SSO flows in different manners, when the SP triggers an SSO operation: SAML 2.0 allows extensive customization via the AuthnRequest message SAML 1.1 does not allow any customization, since the specifications do not define an authentication request message OpenID 2.0 allows for some customization, mainly via the OpenID 2.0 extensions such as PAPE or UI SAML 2.0 OIF/SP allows the customization of the SAML 2.0 AuthnRequest message for the following elements: ForceAuthn: Boolean indicating whether or not the IdP should force the user for re-authentication, even if the user has still a valid session By default set to false IsPassive Boolean indicating whether or not the IdP is allowed to interact with the user as part of the Federation SSO operation. If false, the Federation SSO operation might result in a failure with the NoPassive error code, because the IdP will not have been able to identify the user By default set to false RequestedAuthnContext Element indicating how the user should be challenged at the IdP If the SP requests a Federation Authentication Method unknown to the IdP or for which the IdP is not configured, then the Federation SSO flow will result in a failure with the NoAuthnContext error code By default missing NameIDPolicy Element indicating which NameID format the IdP should include in the SAML Assertion If the SP requests a NameID format unknown to the IdP or for which the IdP is not configured, then the Federation SSO flow will result in a failure with the InvalidNameIDPolicy error code If missing, the IdP will generally use the default NameID format configured for this SP partner at the IdP By default missing ProtocolBinding Element indicating which SAML binding should be used by the IdP to redirect the user to the SP with the SAML Assertion Set to Artifact or HTTP-POST By default set to HTTP-POST OIF/SP also allows the administrator to configure the server to: Set which binding should be used by OIF/SP to redirect the user to the IdP with the SAML 2.0 AuthnRequest message: Redirect or HTTP-POST By default set to Redirect Set which binding should be used by OIF/SP to redirect the user to the IdP during logout with SAML 2.0 Logout messages: Redirect or HTTP-POST By default set to Redirect SAML 1.1 The SAML 1.1 specifications do not define a message for the SP to send to the IdP when a Federation SSO operation is started. As such, there is no capability to configure OIF/SP on how to affect the start of the Federation SSO flow. OpenID 2.0 OpenID 2.0 defines several extensions that can be used by the SP/RP to affect how the Federation SSO operation will take place: OpenID request: mode: String indicating if the IdP/OP can visually interact with the user checkid_immediate does not allow the IdP/OP to interact with the user checkid_setup allows user interaction By default set to checkid_setup PAPE Extension: max_auth_age : Integer indicating in seconds the maximum amount of time since when the user authenticated at the IdP. If MaxAuthnAge is bigger that the time since when the user last authenticated at the IdP, then the user must be re-challenged. OIF/SP will set this attribute to 0 if the administrator configured ForceAuthn to true, otherwise this attribute won't be set Default missing preferred_auth_policies Contains a Federation Authentication Method Element indicating how the user should be challenged at the IdP By default missing Only specified in the OpenID request if the IdP/OP supports PAPE in XRDS, if OpenID discovery is used. UI Extension Popup mode Boolean indicating the popup mode is enabled for the Federation SSO By default missing Language Preference String containing the preferred language, set based on the browser's language preferences. By default missing Icon: Boolean indicating if the icon feature is enabled. In that case, the IdP/OP would look at the SP/RP XRDS to determine how to retrieve the icon By default missing Only specified in the OpenID request if the IdP/OP supports UI Extenstion in XRDS, if OpenID discovery is used. ForceAuthn and IsPassive WLST Command OIF/SP provides the WLST configureIdPAuthnRequest() command to set: ForceAuthn as a boolean: In a SAML 2.0 AuthnRequest, the ForceAuthn field will be set to true or false In an OpenID 2.0 request, if ForceAuthn in the configuration was set to true, then the max_auth_age field of the PAPE request will be set to 0, otherwise, max_auth_age won't be set IsPassive as a boolean: In a SAML 2.0 AuthnRequest, the IsPassive field will be set to true or false In an OpenID 2.0 request, if IsPassive in the configuration was set to true, then the mode field of the OpenID request will be set to checkid_immediate, otherwise set to checkid_setup Test In this test, OIF/SP is integrated with a remote SAML 2.0 IdP Partner, with the OOTB configuration. Based on this setup, when OIF/SP starts a Federation SSO flow, the following SAML 2.0 AuthnRequest would be generated: <samlp:AuthnRequest ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ID="id-E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4" Version="2.0" IssueInstant="2014-04-01T21:39:14Z" Destination="https://acme.com/saml20/sso">   <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sp.com/oam/fed</saml:Issuer>   <samlp:NameIDPolicy AllowCreate="true"/></samlp:AuthnRequest> Let's configure OIF/SP for that IdP Partner, so that the SP will require the IdP to re-challenge the user, even if the user is already authenticated: 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 configureIdPAuthnRequest() command:configureIdPAuthnRequest(partner="AcmeIdP", forceAuthn="true") Exit the WLST environment:exit() After the changes, the following SAML 2.0 AuthnRequest would be generated: <samlp:AuthnRequest ForceAuthn="true" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ID="id-E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4" Version="2.0" IssueInstant="2014-04-01T21:39:14Z" Destination="https://acme.com/saml20/sso">   <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sp.com/oam/fed</saml:Issuer>   <samlp:NameIDPolicy AllowCreate="true"/></samlp:AuthnRequest> To display or delete the ForceAuthn/IsPassive settings, perform the following operatons: 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 configureIdPAuthnRequest() command: To display the ForceAuthn/IsPassive settings on the partnerconfigureIdPAuthnRequest(partner="AcmeIdP", displayOnly="true") To delete the ForceAuthn/IsPassive settings from the partnerconfigureIdPAuthnRequest(partner="AcmeIdP", delete="true") Exit the WLST environment:exit() Requested Fed Authn Method In my earlier "Fed Authentication Method Requests in OIF / SP" article, I discussed how OIF/SP could be configured to request a specific Federation Authentication Method from the IdP when starting a Federation SSO operation, by setting elements in the SSO request message. WLST Command The OIF WLST commands that can be used are: setIdPPartnerProfileRequestAuthnMethod() which will configure the requested Federation Authentication Method in a specific IdP Partner Profile, and accepts the following parameters: partnerProfile: name of the IdP Partner Profile authnMethod: the Federation Authentication Method to request displayOnly: an optional parameter indicating if the method should display the current requested Federation Authentication Method instead of setting it delete: an optional parameter indicating if the method should delete the current requested Federation Authentication Method instead of setting it setIdPPartnerRequestAuthnMethod() which will configure the specified IdP Partner entry with the requested Federation Authentication Method, and accepts the following parameters: partner: name of the IdP Partner authnMethod: the Federation Authentication Method to request displayOnly: an optional parameter indicating if the method should display the current requested Federation Authentication Method instead of setting it delete: an optional parameter indicating if the method should delete the current requested Federation Authentication Method instead of setting it This applies to SAML 2.0 and OpenID 2.0 protocols. See the "Fed Authentication Method Requests in OIF / SP" article for more information. Test In this test, OIF/SP is integrated with a remote SAML 2.0 IdP Partner, with the OOTB configuration. Based on this setup, when OIF/SP starts a Federation SSO flow, the following SAML 2.0 AuthnRequest would be generated: <samlp:AuthnRequest ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ID="id-E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4" Version="2.0" IssueInstant="2014-04-01T21:39:14Z" Destination="https://acme.com/saml20/sso">   <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sp.com/oam/fed</saml:Issuer>   <samlp:NameIDPolicy AllowCreate="true"/></samlp:AuthnRequest> Let's configure OIF/SP for that IdP Partner, so that the SP will request the IdP to use a mechanism mapped to the urn:oasis:names:tc:SAML:2.0:ac:classes:X509 Federation Authentication Method to authenticate the user: 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 setIdPPartnerRequestAuthnMethod() command:setIdPPartnerRequestAuthnMethod("AcmeIdP", "urn:oasis:names:tc:SAML:2.0:ac:classes:X509") Exit the WLST environment:exit() After the changes, the following SAML 2.0 AuthnRequest would be generated: <samlp:AuthnRequest ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ID="id-E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4" Version="2.0" IssueInstant="2014-04-01T21:39:14Z" Destination="https://acme.com/saml20/sso">   <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sp.com/oam/fed</saml:Issuer>   <samlp:NameIDPolicy AllowCreate="true"/>   <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:X509      </saml:AuthnContextClassRef>   </samlp:RequestedAuthnContext></samlp:AuthnRequest> NameID Format The SAML 2.0 protocol allows for the SP to request from the IdP a specific NameID format to be used when the Assertion is issued by the IdP. Note: SAML 1.1 and OpenID 2.0 do not provide such a mechanism Configuring OIF The administrator can configure OIF/SP to request a NameID format in the SAML 2.0 AuthnRequest via: The OAM Administration Console, in the IdP Partner entry The OIF WLST setIdPPartnerNameIDFormat() command that will modify the IdP Partner configuration OAM Administration Console To configure the requested NameID format via the OAM Administration Console, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Open the IdP Partner you wish to modify In the Authentication Request NameID Format dropdown box with one of the values None The NameID format will be set Default Email Address The NameID format will be set urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress X.509 Subject The NameID format will be set urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName Windows Name Qualifier The NameID format will be set urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName Kerberos The NameID format will be set urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos Transient The NameID format will be set urn:oasis:names:tc:SAML:2.0:nameid-format:transient Unspecified The NameID format will be set urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified Custom In this case, a field would appear allowing the administrator to indicate the custom NameID format to use The NameID format will be set to the specified format Persistent The NameID format will be set urn:oasis:names:tc:SAML:2.0:nameid-format:persistent I selected Email Address in this example Save WLST Command To configure the requested NameID format via the OIF WLST setIdPPartnerNameIDFormat() command, perform the following steps: 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 setIdPPartnerNameIDFormat() command:setIdPPartnerNameIDFormat("PARTNER", "FORMAT", customFormat="CUSTOM") Replace PARTNER with the IdP Partner name Replace FORMAT with one of the following: orafed-none The NameID format will be set Default orafed-emailaddress The NameID format will be set urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress orafed-x509 The NameID format will be set urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName orafed-windowsnamequalifier The NameID format will be set urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName orafed-kerberos The NameID format will be set urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos orafed-transient The NameID format will be set urn:oasis:names:tc:SAML:2.0:nameid-format:transient orafed-unspecified The NameID format will be set urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified orafed-custom In this case, a field would appear allowing the administrator to indicate the custom NameID format to use The NameID format will be set to the specified format orafed-persistent The NameID format will be set urn:oasis:names:tc:SAML:2.0:nameid-format:persistent customFormat will need to be set if the FORMAT is set to orafed-custom An example would be:setIdPPartnerNameIDFormat("AcmeIdP", "orafed-emailaddress") Exit the WLST environment:exit() Test In this test, OIF/SP is integrated with a remote SAML 2.0 IdP Partner, with the OOTB configuration. Based on this setup, when OIF/SP starts a Federation SSO flow, the following SAML 2.0 AuthnRequest would be generated: <samlp:AuthnRequest ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ID="id-E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4" Version="2.0" IssueInstant="2014-04-01T21:39:14Z" Destination="https://acme.com/saml20/sso">   <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sp.com/oam/fed</saml:Issuer> <samlp:NameIDPolicy AllowCreate="true"/></samlp:AuthnRequest> After the changes performed either via the OAM Administration Console or via the OIF WLST setIdPPartnerNameIDFormat() command where Email Address would be requested as the NameID Format, the following SAML 2.0 AuthnRequest would be generated: <samlp:AuthnRequest ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ID="id-E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4" Version="2.0" IssueInstant="2014-04-01T21:39:14Z" Destination="https://acme.com/saml20/sso">   <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sp.com/oam/fed</saml:Issuer> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/></samlp:AuthnRequest> Protocol Binding The SAML 2.0 specifications define a way for the SP to request which binding should be used by the IdP to redirect the user to the SP with the SAML 2.0 Assertion: the ProtocolBinding attribute indicates the binding the IdP should use. It is set to: Either urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST for HTTP-POST Or urn:oasis:names:tc:SAML:2.0:bindings:Artifact for Artifact The SAML 2.0 specifications also define different ways to redirect the user from the SP to the IdP with the SAML 2.0 AuthnRequest message, as the SP can send the message: Either via HTTP Redirect Or HTTP POST (Other bindings can theoretically be used such as Artifact, but these are not used in practice) Configuring OIF OIF can be configured: Via the OAM Administration Console or the OIF WLST configureSAMLBinding() command to set the Assertion Response binding to be used Via the OIF WLST configureSAMLBinding() command to indicate how the SAML AuthnRequest message should be sent Note: the binding for sending the SAML 2.0 AuthnRequest message will also be used to send the SAML 2.0 LogoutRequest and LogoutResponse messages. OAM Administration Console To configure the SSO Response/Assertion Binding via the OAM Administration Console, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Open the IdP Partner you wish to modify Check the "HTTP POST SSO Response Binding" box to request the IdP to return the SSO Response via HTTP POST, otherwise uncheck it to request artifact Save WLST Command To configure the SSO Response/Assertion Binding as well as the AuthnRequest Binding via the OIF WLST configureSAMLBinding() command, perform the following steps: 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 configureSAMLBinding() command:configureSAMLBinding("PARTNER", "PARTNER_TYPE", binding, ssoResponseBinding="httppost") Replace PARTNER with the Partner name Replace PARTNER_TYPE with the Partner type (idp or sp) Replace binding with the binding to be used to send the AuthnRequest and LogoutRequest/LogoutResponse messages (should be httpredirect in most case; default) httppost for HTTP-POST binding httpredirect for HTTP-Redirect binding Specify optionally ssoResponseBinding to indicate how the SSO Assertion should be sent back httppost for HTTP-POST binding artifactfor for Artifact binding An example would be:configureSAMLBinding("AcmeIdP", "idp", "httpredirect", ssoResponseBinding="httppost") Exit the WLST environment:exit() Test In this test, OIF/SP is integrated with a remote SAML 2.0 IdP Partner, with the OOTB configuration which requests HTTP-POST from the IdP to send the SSO Assertion. Based on this setup, when OIF/SP starts a Federation SSO flow, the following SAML 2.0 AuthnRequest would be generated: <samlp:AuthnRequest ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ID="id-E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4" Version="2.0" IssueInstant="2014-04-01T21:39:14Z" Destination="https://acme.com/saml20/sso">   <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sp.com/oam/fed</saml:Issuer>   <samlp:NameIDPolicy AllowCreate="true"/></samlp:AuthnRequest> In the next article, I will cover the various crypto configuration properties in OIF that are used to affect the Federation SSO exchanges.Cheers,Damien Carru

In this article, I will list the various OIF/SP settings that affect how an AuthnRequest message is created in OIF in a Federation SSO flow. The AuthnRequest message is used by an SP to start...

Integrating Google Apps with OIF / IdP

Google Apps provide a set of services that companies sometimes leverage for their day to day activities, which allow their employees to offload mail, calendar, document storage... in the Google cloud. When a company purchases Google Apps for its employees, it needs to create user accounts in Google and provide the employees with their account information: Username and password to access Google Apps How to set/reset their password in Google Apps (initially, or if the password needs to be reset periodically) Every time the user needs to access Google Apps, an authentication operation will take place where the user will enter the Google Apps credentials, which will be different from the on-premise company's user credentials. Google Apps supports the SAML 2.0 SSO protocol as a Service Provider, where the Google Apps service for the company can be integrated with the on-premise Federation SSO IdP server in order to: Provide true SSO capabilities for the user: the user authentication state is propagated from the on-premise security domain to Google Apps Not force the user to manage and remember a different set of credentials Allow the on-premise administrator to control more efficiently password policies locally. In this article, I will describe step by step how to integrate Google Apps as an SP with OIF as an IdP via the SAML 2.0 SSO protocol. Important note: enabling Federation SSO for a domain will also affect the administrators for that domain who will need to authenticate via Federation SSO thereafter. Enjoy the reading! User Mapping Users in Google Apps are uniquely identified by their email addresses which was set when those users were created. During a SAML 2.0 SSO flow, the IdP will need to provide the user ID to Google Apps: In the SAML 2.0 NameID field With the NameID value set: Either to the user's email address at Google Apps Or the identifying part of the email address (ie: before the @ character) As an example, I will show the information the IdP should send for company ACME which purchased a Google Apps service, for their acme.com domain. To view a user account in Google Apps, perform the following steps: Launch a browser Go to http://www.google.com/a Click Sign In Perform the following steps: In the domain field, enter the name of your domain (in this example, www.acme.com) Select Admin Console Click Go Perform the following steps: In the Dashboard, click on Users Perform the following steps: Select a user to view The next screen will show details about the user. The email address is displayed underneath the user's identity. In this example, the ACME IdP will have to send to Google Apps either alice or alice@acme.com during the SAML 2.0 SSO operation: OIF/IdP Configuration Google Apps Identifier Google Apps can be configured by the Google Apps administrator to be known to the IdP: Either as google.com Or as google.com/a/<YOUR_DOMAIN.COM> (for example: google.com/a/acme.com) This behavior is dictated by the "Use a domain specific issuer" in the Google Apps SSO admin section. Typically, you would not need to use a specific issuer/providerID, and Google Apps in the SAML 2.0 SSO flow would be known as google.com. Google Apps SP Partner To create Google Apps as an SP Partner, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the “Create Service Provider Partner” button In the Create screen: Enter a name for the partner: GoogleApps for example Select SAML 2.0 as the Protocol In the Service Details: Click Enter Manually Set the Provider ID to google.com (if in Google Apps you enabled the "Use a domain specific issuer" feature, you would enter google.com/a/<YOUR_DOMAIN.COM>). Set the Assertion Consumer URL to https://www.google.com/a/<YOUR_DOMAIN.COM>/acs (for example https://www.google.com/a/acme.com/acs) Select Email Address as the NameID format Select the LDAP User Attribute containing the userID that will need to be provided to Google Apps. In my example, the uid attribute contained the userID: select User ID Store Attribute then enter uid Select the Attribute Profile that will be used to populate the SAML Assertion with attributes (default empty profile is acceptable since Google Apps does not expect any SAML Attributes other than the NameID) Click Save Collecting OIF Information The following information will need to be provided into the Google Apps SSO Admin console: SAML 2.0 SSO IdP endpoint X.509 Signing Certificate used by the IdP to sign the SAML 2.0 Assertion In this earlier article, I listed the endpoints published by OIF. The SAML 2.0 SSO IdP endpoint and the SAML 2.0 logout endpoint would be http(s)://oam-public-hostname:oam-public-port/oamfed/idp/samlv20, with oam-public-hostname and oam-public-port being the values of the public endpoint, where the user will access the OAM/OIF application (load balancer, HTTP reverse proxy...). If you are unsure about the oam-public-hostname and oam-public-port, you can: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Access Manager Settings The oam-public-hostname  is the OAM Server Host, the oam-public-port is the OAM Server Port and the protocol (http or https) is listed in OAM Server Protocol. In the same article, I also explained how to determine which key entry is used to sign SAML messages and how to retrieve the corresponding Signing Certificate used by OIF/IdP: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Federation Settings The Signing Key field in the General section indicates which key ID entry is used for SAML message signature operations To retrieve the certificate file of a specific key ID, open a browser and use the following URL to retrieve the certificate and save it locally:http://oam-runtime-host:oam-runtime-port/oamfed/idp/cert?id=<KEYENTRY_ID> The id query parameter contains the key entry ID for the certificate. Replace <KEYENTRY_ID> An example would be:http://acme.com/oamfed/idp/cert?id=osts_signing  Google Apps Configuration To configure Google Apps for SAML 2.0 SSO flow, perform the following steps: Launch a browser Go to https://www.google.com/enterprise/apps/business/ Authenticate and go to the Admin Dashboard Click on More Controls Perform the following steps: Click Security Perform the following steps: Click Advanced Settings Perform the following steps: Click "Set up single sign-on (SSO)" In the SSO Setup page, upload the certificate: In the Verification Certificate section, click Choose file Select the OIF IdP certificate saved earlier Click upload In the SSO Setup page, to set up the URLs and enable Federation SSO: Enter the Sign-in URL (IdP SAML 2.0 SSO endpoint), similar to http(s)://oam-public-hostname:oam-public-port/oamfed/idp/samlv20 (for example: https://sso.acme.com/oamfed/idp/samlv20) Enter the Sign-out URL (IdP SAML 2.0 Logout endpoint), similar to http(s)://oam-public-hostname:oam-public-port/oamfed/idp/samlv20 (for example: https://sso.acme.com/oamfed/idp/samlv20) Enter the Change Password URL for your deployment (note: in this example I use /changePassword, but this is not an OAM/OIF service; you would need to enter the Password Management service URL for your deployment) Check the "Enable Single Sign-On" to turn on Federation SSO Save Testing To test: Open a fresh browser Go to these URLs to authenticate via Federation SSO for the following Google Apps: Gmail: https://mail.google.com/a/<YOUR_DOMAIN.COM>/ (for example https://mail.google.com/a/acme.com/) Calendar: https://calendar.google.com/a/<YOUR_DOMAIN.COM>/ (for example https://calendar.google.com/a/acme.com/) Documents: https://docs.google.com/a/<YOUR_DOMAIN.COM>/ (for example https://docs.google.com/a/acme.com/) Enter the Gmail URL for example You will be redirected to OIF IdP Enter your credentials Perform the following steps: Click Login The Gmail application will be displayed: In the next article, I will cover the various settings that can be used to configure OIF/SP for sending an SSO Request, when the Federation SSO flow starts.Cheers,Damien Carru

Google Apps provide a set of services that companies sometimes leverage for their day to day activities, which allow their employees to offload mail, calendar, document storage... in the Google cloud. W...

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

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...

Fed Authentication Method Requests 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!ProtocolsOIF/SP can request a specific Federation Authentication Method to be used at the remote IdP Partner, only if the protocol used between the two servers supports such a mechanism:SAML 2.0 defines the RequestedAuthnContext element in the SAML 2.0 AuthnRequest message SAML 1.1 does not define a way for the SP to request a Federation Authentication Method OpenID 2.0 defines the PAPE extension where the SP can specify the policies to be usedWLST CommandsOIF/SP can be configured to request a specific Federation Authentication Method via:An IdP Partner Profile which would apply to all IdP Partners bound to this profileAn IdP Partner, which in this case would only apply to this partnerThe OIF WLST commands that can be used are:setIdPPartnerProfileRequestAuthnMethod() which will configure the requested Federation Authentication Method in a specific IdP Partner Profile, and accepts the following parameters:partnerProfile: name of the IdP Partner ProfileauthnMethod: the Federation Authentication Method to requestdisplayOnly: an optional parameter indicating if the method should display the current requested Federation Authentication Method instead of setting itdelete: an optional parameter indicating if the method should delete the current requested Federation Authentication Method instead of setting itsetIdPPartnerRequestAuthnMethod() which will configure the specified IdP Partner entry with the requested Federation Authentication Method, and accepts the following parameters:partner: name of the IdP PartnerauthnMethod: the Federation Authentication Method to requestdisplayOnly: an optional parameter indicating if the method should display the current requested Federation Authentication Method instead of setting itdelete: an optional parameter indicating if the method should delete the current requested Federation Authentication Method instead of setting itSAML 2.0Test SetupIn 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 MethodThe 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:X509In the following tests, I will perform Federation SSO with OIF/SP configured to:Perform Federation SSO with the SP not requesting a Federation Authentication MethodPerform Federation SSO with the SP requesting urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransportPerform Federation SSO with the SP requesting urn:oasis:names:tc:SAML:2.0:ac:classes:X509Perform Federation SSO with the SP requesting urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKISP not Requesting a Fed Authn MethodIn a typical Federation SSO operation, the SP would not request a specific Federation Authentication Method to be used to challenge the user.The SAML 2.0 AuthnRequest would be similar to:<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://acmeidp.com/saml20/sso" ID="id-8bWn-A9o4aoMl3Nhx1DuPOOjawc-" IssueInstant="2014-03-21T20:51:11Z" Version="2.0">  <saml:Issuer ...>https://sp.com</saml:Issuer>  <samlp:NameIDPolicy AllowCreate="false" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/></samlp:AuthnRequest>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>SP Requesting PasswordProtectedTransportIn this flow, OIF/SP requests the remote IdP to use urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport as the Federation Authentication Method for the user challenge.To configure OIF/SP so that it will request urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport  from the IdP, I will use the setIdPPartnerRequestAuthnMethod() to configure the IdP Partner:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setIdPPartnerRequestAuthnMethod() command:setIdPPartnerRequestAuthnMethod("AcmeIdP", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport")Exit the WLST environment:exit()The SAML 2.0 AuthnRequest would be similar to:<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://acmeidp.com/saml20/sso" ID="id-8bWn-A9o4aoMl3Nhx1DuPOOjawc-" IssueInstant="2014-03-21T20:51:11Z" Version="2.0">  <saml:Issuer ...>https://sp.com</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>The IdP will challenge the user with the authentication 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>SP Requesting X509In this flow, OIF/SP requests the remote IdP to use urn:oasis:names:tc:SAML:2.0:ac:classes:X509 as the Federation Authentication Method for the user challenge.To configure OIF/SP so that it will request urn:oasis:names:tc:SAML:2.0:ac:classes:X509 from the IdP, I will use the setIdPPartnerRequestAuthnMethod() to configure the IdP Partner:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setIdPPartnerRequestAuthnMethod() command:setIdPPartnerRequestAuthnMethod("AcmeIdP", "urn:oasis:names:tc:SAML:2.0:ac:classes:X509")Exit the WLST environment:exit()The SAML 2.0 AuthnRequest would be similar to:<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://acmeidp.com/saml20/sso" ID="id-8bWn-A9o4aoMl3Nhx1DuPOOjawc-" IssueInstant="2014-03-21T20:51:11Z" Version="2.0">  <saml:Issuer ...>https://sp.com</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:X509    </saml:AuthnContextClassRef>  </samlp:RequestedAuthnContext></samlp:AuthnRequest>The IdP will challenge the user with the authentication 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>SP Requesting SmartcardPKIIn this flow, OIF/SP requests the remote IdP to use urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI as the Federation Authentication Method for the user challenge. This test will result in an error, because the IdP does not support that Federation Authentication Method.To configure OIF/SP so that it will request urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI from the IdP, I will use the setIdPPartnerRequestAuthnMethod() to configure the IdP Partner:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setIdPPartnerRequestAuthnMethod() command:setIdPPartnerRequestAuthnMethod("AcmeIdP", "urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI")Exit the WLST environment:exit()The SAML 2.0 AuthnRequest would be similar to:<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://acmeidp.com/saml20/sso" ID="id-8bWn-A9o4aoMl3Nhx1DuPOOjawc-" IssueInstant="2014-03-21T20:51:11Z" Version="2.0">  <saml:Issuer ...>https://sp.com</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:SmartcardPKI    </saml:AuthnContextClassRef>  </samlp:RequestedAuthnContext></samlp:AuthnRequest>The IdP will not challenge the user and instead will return a SAML 2.0 Response with the low level status code set to urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext.The SAML 2.0 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:Requester">         <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext"/>      </samlp:StatusCode>   </samlp:Status></samlp:Response>Note About ComparisonIf OIF/SP is configured to request a Federation Authentication Method from a remote IdP Partner, it will set by default the Comparison flag in the SAML 2.0 AuthnRequest to minimum.This SAML 2.0 parameter can be one of the following:minimumexactmaximumbetter<empty>, and exact will be assumed by the IdPIf it is required to change that flag to another value, an OIF WLST command can be used to update the configuration:At the IdP Partner Profile level, the putStringProperty() method will be used:putStringProperty("/fedpartnerprofiles/saml20-idp-partner-profile/PARTNER_PROFILE_NAME", VALUE)PARTNER_PROFILE_NAME is the name of the IdP Partner ProfileVALUE is the value that will be stored in the Comparison flag, and must be one of the following values:minimumexactmaximumbetternoneAn example would be:putStringProperty("/fedpartnerprofiles/saml20-idp-partner-profile/saml20-idp-partner-profile", "exact")At the IdP Partner Profile level, the updatePartnerProperty() method will be used:updatePartnerProperty(PARTNER_NAME, "idp", "requestauthncomparison", VALUE)PARTNER_NAME is the name of the IdP PartnerVALUE is the value that will be stored in the Comparison flag, and must be one of the following values:minimumexactmaximumbetternoneAn example would be:updatePartnerProperty("AcmeIdP", "idp", "requestauthncomparison", "exact")OpenID 2.0Test SetupIn this setup, OIF is acting as an SP/RP and is integrated with a remote OpenID 2.0 IdP/OP partner identified by AcmeOP:By default, OIF/SP is not configured to request any Federation Authentication MethodThe remote IdP supports the following Federation Authentication Methods http://schemas.openid.net/pape/policies/2007/06/phishing-resistantIn the following tests, I will perform Federation SSO with OIF/SP configured to:Perform Federation SSO with the SP not requesting a Federation Authentication MethodPerform Federation SSO with the SP requesting http://schemas.openid.net/pape/policies/2007/06/phishing-resistantSP not Requesting a Fed Authn MethodIn a typical Federation SSO operation, the SP would not request a specific Federation Authentication Method to be used to challenge the user.The OpenID 2.0 SSO Request would be similar to (note that there is no PAPE Request attributes in the request, since the SP/RP did not request anything):https://acmeOP.com/openid20?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-m4wzOs9Vigl-lTxvvWFql0HpGj8-&openid.return_to=https%3A%2F%sp.com%2Foam%2Fserver%2Ffed%2Fsp%2Fsso%3Frefid%3Did-JJ06syDyCELqLWDqRHGcI9sQI1DTBzouDL6qSKiE&openid.realm=https%3A%2F%sp.com&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_request&openid.ax.type.attr0=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.type.attr1=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.required=attr0%2Cattr1The IdP will challenge the user with its default authentication mechanism, and the SSO Response will not contain any PAPE Response attributes, since the request did not contain any PAPE elements.The OpenID 2.0 SSO Response would be similar to:https://sp.com/oam/server/fed/sp/sso?refid=id-JJ06syDyCELqLWDqRHGcI9sQI1DTBzouDL6qSKiE&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Facmeop.com%2Fopenid20&openid.claimed_id=https%3A%2F%2Facmeop.com%2Fopenid20%3Fid%3Did-YxEgHp7b49OrDy9dJP4BWrwbNUQ-&openid.identity=https%3A%2F%2Facmeop.com%2Fopenidv20%3Fid%3Did-YxEgHp7b49OrDy9dJP4BWrwbNUQ-&openid.return_to=https%3A%2F%2Fsp.com%2Foam%2Fserver%2Ffed%2Fsp%2Fsso%3Frefid%3Did-JJ06syDyCELqLWDqRHGcI9sQI1DTBzouDL6qSKiE&openid.response_nonce=2014-03-27T19%3A06%3A59Zid-AI5SSUN4A2yEtUPRSw5-byMbyR8-&openid.assoc_handle=id-m4wzOs9Vigl-lTxvvWFql0HpGj8-&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_response&openid.ax.type.attr0=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.value.attr0=alice&openid.ax.type.attr1=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.value.attr1=alice%40oracle.com&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&openid.sig=rzSC1Oa%2Bvpba2z%2Fh0HzpS3R2DO8%3DSP Requesting phishing-resistantIn this flow, OIF/SP requests the remote IdP to use http://schemas.openid.net/pape/policies/2007/06/phishing-resistant as the Federation Authentication Method for the user challenge.To configure OIF/SP so that it will request http://schemas.openid.net/pape/policies/2007/06/phishing-resistantfrom the IdP, I will use the setIdPPartnerRequestAuthnMethod() to configure the IdP Partner:Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the setIdPPartnerRequestAuthnMethod() command:setIdPPartnerRequestAuthnMethod("AcmeOP", "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant")Exit the WLST environment:exit()The OpenID 2.0 SSO Request would be similar to (note that there is a PAPE Request attributes in the request this time):https://acme.com/openid20?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-eL-ODTYp5StXeXbmpSEs-eUQtG8-&openid.return_to=https%3A%2F%2Fsp.com%2Foam%2Fserver%2Ffed%2Fsp%2Fsso%3Frefid%3Did-4TmXY8UvwwssPI-IUYjTX-NMxz1wlkAZ7q0ABE-L&openid.realm=https%3A%2F%2Fsp.com&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_request&openid.ax.type.attr0=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.type.attr1=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.required=attr0%2Cattr1&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.preferred_auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fphishing-resistantThe IdP will challenge the user with the authentication mapped to http://schemas.openid.net/pape/policies/2007/06/phishing-resistant and the SSO Response will not contain PAPE Response attributes.The OpenID 2.0 SSO Response would be similar to:https://sp.com/oam/server/fed/sp/sso?refid=id-4TmXY8UvwwssPI-IUYjTX-NMxz1wlkAZ7q0ABE-L&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Facmeop.com%2Fopenid20&openid.claimed_id=https%3A%2F%2Facmeop.com%2Fopenid20%3Fid%3Did-YxEgHp7b49OrDy9dJP4BWrwbNUQ-&openid.identity=https%3A%2F%2Facmeop.com%2Fopenid20%3Fid%3Did-YxEgHp7b49OrDy9dJP4BWrwbNUQ-&openid.return_to=https%3A%2F%2Fsp.com%2Foam%2Fserver%2Ffed%2Fsp%2Fsso%3Frefid%3Did-4TmXY8UvwwssPI-IUYjTX-NMxz1wlkAZ7q0ABE-L&openid.response_nonce=2014-03-27T19%3A24%3A21Zid-q61psPKlfNHFelE3XBymqi22jM0-&openid.assoc_handle=id-eL-ODTYp5StXeXbmpSEs-eUQtG8-&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_response&openid.ax.type.attr0=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.value.attr0=alice&openid.ax.type.attr1=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.value.attr1=alice%40oracle.com&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_time=2014-03-27T19%3A24%3A20Z&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2F2Fphishing-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%2Cns.pape%2Cpape.auth_time%2Cpape.auth_policies&openid.sig=WhDkc14KTGVSiqdzvfHoWKaYiCw%3D In the next article, I will discuss about how to map Federation Authentication Mapping to Authentication Levels in OIF/SP, when creating the OAM User Session after processing the Federation SSO Response.Cheers,Damien Carru

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...

Fed Authentication Method Requests in OIF / IdP

In my previous article, I explained how to configure OIF/IdP to map OAM Authentication Schemes to Federation Authentication Methods, for OIF/IdP to be able to map the OAM Authentication Scheme to a Federation Authentication Method when issuing an SSO Response. In this post, I will describe how to set up OIF/IdP, so that an SP can request the user to be authenticated via a specific OAM Authentication Scheme. The approach is based on the Federation Authentication Methods and their mappings to OAM Authentication Schemes. In a recent article, I explained that: Each defined 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 The examples will show how to indicate to OIF/IdP which Authentication Scheme to use to challenge the user, when the SP requests a specific Federation Authentication Method to be used. Configuration Similarly to the examples listed in the previous post, 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), and this can be done: 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. WLST Commands The same OIF WLST commands used to map Federation Authentication Methods to OAM Authentication Schemes are used to indicate a scheme to be used when an SP request a user to be challenged via a specificFederation Authentication Method : addSPPartnerProfileAuthnMethod() to define a mapping on an SP Partner Profile, taking as parameters: The name of the SP Partner Profile The Federation Authentication Method The OAM Authentication Scheme name A default flag indicating if this scheme should be the one used for authentication, when the SP/RP Partner requests this Federation Authentication Method to be used at runtime addSPPartnerAuthnMethod() to define a mapping on an SP Partner , taking as parameters: The name of the SP Partner The Federation Authentication Method The OAM Authentication Scheme name A default flag indicating if this scheme should be the one used for authentication, when the SP/RP Partner requests this Federation Authentication Method to be used at runtime In the next section, I will show examples on how to use the addSPPartnerProfileAuthnMethod() with the SAML 2.0 protocol. Note: SAML 1.1 does not support a way for the SP to request a specific Federation Authentication Method. Example Test Setup In this setup, OIF is acting as an IdP and is integrated with a remote SAML 2.0 SP partner identified by AcmeSP. By default: LDAPScheme is the default Authentication Scheme 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, and the profile referenced by AcmeSP (getFedPartnerProfile("AcmeSP", "sp") ) In this test, I will perform Federation SSO with OIF/IdP configured to: Perform Federation SSO with the SP not specifying a Federation Authentication Method Perform Federation SSO with the SP specifying urn:oasis:names:tc:SAML:2.0:ac:classes:Password as the Federation Authentication Method Defining the urn:oasis:names:tc:SAML:2.0:ac:classes:Password mapping to LDAPScheme, mark LDAPScheme as the default scheme for this mapping, and perform Federation SSO with the SP specifying urn:oasis:names:tc:SAML:2.0:ac:classes:Password as the Federation Authentication Method Adding BasicScheme to the urn:oasis:names:tc:SAML:2.0:ac:classes:Password mapping, and perform Federation SSO with the SP specifying urn:oasis:names:tc:SAML:2.0:ac:classes:Password as the Federation Authentication Method Setting BasicScheme as the default scheme for the urn:oasis:names:tc:SAML:2.0:ac:classes:Password mapping, and perform Federation SSO with the SP specifying urn:oasis:names:tc:SAML:2.0:ac:classes:Password as the Federation Authentication Method SP not Requesting a Fed Authn Method In a typical Federation SSO operation, the SP would not request a specific Federation Authentication Method to be used to challenge the user. The SAML 2.0 AuthnRequest would be similar to: <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:AuthnRequest> Since the settings are OOTB, the global default Authentication Scheme would be used for authentication, which is LDAPScheme. Test: during the Federation SSO operation where the SP does not request a specific Federation Authentication Method to be used, the user would be challenged by OAM using LDAPScheme. SP Requesting a Fed Authn Method In this flow, the SP requests OIF/IdP to use a specific Federation Authentication Method to be used to challenge the user. This method is urn:oasis:names:tc:SAML:2.0:ac:classes:Password, and this will be requested by the SP for all subsequent tests in this article. The SAML 2.0 AuthnRequest would be similar to: <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:Password </saml:AuthnContextClassRef>  </samlp:RequestedAuthnContext></samlp:AuthnRequest> Since OOTB the urn:oasis:names:tc:SAML:2.0:ac:classes:Password Federation Authentication Method is not defined in OIF/IdP, the server would return an error to the SP, indicating that this Federation Authentication Method is unknown at OIF/IdP: the server would send a SAML 2.0 Response with the low level status code set to urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext. The SAML 2.0 Response would be similar to: <samlp:Response ...>   <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>   <samlp:Status>      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">         <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext"/>      </samlp:StatusCode>   </samlp:Status></samlp:Response> Test: during the Federation SSO operation where the SP requests urn:oasis:names:tc:SAML:2.0:ac:classes:Password as the Federation Authentication Method to be used, the operation would result in an error. Creating Fed Authn Mapping To correct the error seen above, I will need to define the urn:oasis:names:tc:SAML:2.0:ac:classes:Password Federation Authentication Method mapped to LDAPScheme: that way, when the SP will request that method, LDAPScheme will be used. Note: by doing so, I am removing the existing mapping between urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport and LDAPScheme, and will only be mapped to BasicScheme, BasicFAScheme and FAAuthScheme. To create the mapping, execute the following steps: 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 addSPPartnerProfileAuthnMethod() command:addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:Password", "LDAPScheme") Exit the WLST environment:exit() I did not specify that LDAPScheme should be used as the default scheme if an SP requests the urn:oasis:names:tc:SAML:2.0:ac:classes:Password during Federation SSO, because the WLST command is defined such as if the isDefault parameter is missing, it is assumed to be true. Test: during the Federation SSO operation where the SP requests urn:oasis:names:tc:SAML:2.0:ac:classes:Password as the Federation Authentication Method to be used, the user would be challenged via LDAPScheme. Adding BasicScheme to the Fed Authn Mapping In this example, I will add the BasicScheme to the list of schemes mapped to the urn:oasis:names:tc:SAML:2.0:ac:classes:Password Federation Authentication Method, but I will not indicate that BasicScheme should be used if the SP requests urn:oasis:names:tc:SAML:2.0:ac:classes:Password at runtime to challenge the user. Note: by doing so, I am removing the existing mapping between urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport and BasicScheme, and will only be mapped to BasicFAScheme and FAAuthScheme. To create the mapping, execute the following steps: 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 addSPPartnerProfileAuthnMethod() command:addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:Password", "BasicScheme", isDefault="false") Exit the WLST environment:exit() I specified that the BasicScheme should not be used as the default scheme if an SP requests the urn:oasis:names:tc:SAML:2.0:ac:classes:Password during Federation SSO. Test: during the Federation SSO operation where the SP requests urn:oasis:names:tc:SAML:2.0:ac:classes:Password as the Federation Authentication Method to be used, the user would be challenged via LDAPScheme. Setting BasicScheme to be used for User Challenge In this example, I will indicate that BasicScheme should be used if the SP requests urn:oasis:names:tc:SAML:2.0:ac:classes:Password at runtime to challenge the user. The command issued will be similar to the previous command, except that the isDefault parameter will be set to true: 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 addSPPartnerProfileAuthnMethod() command:addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:Password", "BasicScheme", isDefault="true") Exit the WLST environment:exit() Test: during the Federation SSO operation where the SP requests urn:oasis:names:tc:SAML:2.0:ac:classes:Password as the Federation Authentication Method to be used, the user would be challenged via BasicScheme. In the next article, I will cover how OIF/SP can be configured to request a Federation Authentication Method from a remote IdP at runtime during Federation SSO.Cheers,Damien Carru

In my previous article, I explained how to configure OIF/IdP to map OAM Authentication Schemes to Federation Authentication Methods, for OIF/IdP to be able to map the OAM Authentication Scheme to a...

Configuring Fed Authentication Methods in OIF / IdP

In this article, I will provide examples on how to configure OIF/IdP to map OAM Authentication Schemes to Federation Authentication Methods, based on the concepts introduced in my previous entry. I will show examples for the three protocols supported by OIF: SAML 2.0 SSO SAML 1.1 SSO OpenID 2.0 Enjoy the reading! Configuration As I mentioned in my previous article, 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. WLST Commands The two OIF WLST commands that can be used to define mapping Federation Authentication Methods to OAM Authentication Schemes are: addSPPartnerProfileAuthnMethod() to define a mapping on an SP Partner Profile, taking as parameters: The name of the SP Partner Profile The Federation Authentication Method The OAM Authentication Scheme name addSPPartnerAuthnMethod() to define a mapping on an SP Partner , taking as parameters: The name of the SP Partner The Federation Authentication Method The OAM Authentication Scheme name Note: I will discuss in a subsequent article the other parameters of those commands. In the next sections, I will show examples on how to use those methods: For SAML 2.0, I will configure the SP Partner Profile, that will apply all the mappings to SP Partners referencing this profile, unless they override mapping definition For SAML 1.1, I will configure the SP Partner. For OpenID 2.0, I will configure the SP/RP Partner SAML 2.0 Test Setup In this setup, OIF is acting as an IdP and is integrated with a remote SAML 2.0 SP partner identified by AcmeSP. In this test, I will perform Federation SSO with OIF/IdP configured to: Use LDAPScheme as the Authentication Scheme Use BasicScheme as the Authentication Scheme Map BasicSessionScheme  to  the urn:oasis:names:tc:SAML:2.0:ac:classes:Password Federation Authentication Method Use OAMLDAPPluginAuthnScheme as the Authentication Scheme Map OAMLDAPPluginAuthnScheme to  the urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport Federation Authentication Method LDAPScheme as Authentication Scheme Using the OOTB settings regarding user authentication in OAM, the user will be challenged via a FORM based login page based on the LDAPScheme. Also the default Federation Authentication Method mappings configuration maps only the urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport to LDAPScheme (also marked as the default scheme used for authentication), FAAuthScheme, BasicScheme and BasicFAScheme. After authentication via FORM, OIF/IdP would issue an Assertion similar to: <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 ...>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://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> BasicScheme as Authentication Scheme For this test, I will switch the default Authentication Scheme for the SP Partner Profile to BasicScheme instead of LDAPScheme. I will use the OIF WLST setSPPartnerProfileDefaultScheme() command and specify which scheme to be used as the default for the SP Partner Profile referenced by AcmeSP (which is saml20-sp-partner-profile in this case: getFedPartnerProfile("AcmeSP", "sp") ): 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 setSPPartnerProfileDefaultScheme() command:setSPPartnerProfileDefaultScheme("saml20-sp-partner-profile", "BasicScheme") Exit the WLST environment:exit() The user will now be challenged via HTTP Basic Authentication defined in the BasicScheme for AcmeSP. Also, as noted earlier, the default Federation Authentication Method mappings configuration maps only the urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport to LDAPScheme (also marked as the default scheme used for authentication), FAAuthScheme, BasicScheme and BasicFAScheme. After authentication via HTTP Basic Authentication, OIF/IdP would issue an Assertion similar to: <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 ...>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://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> Mapping BasicScheme To change the Federation Authentication Method mapping for the BasicScheme to urn:oasis:names:tc:SAML:2.0:ac:classes:Password instead of urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport for the saml20-sp-partner-profile SAML 2.0 SP Partner Profile (the profile to which my AcmeSP Partner is bound to), I will execute the addSPPartnerProfileAuthnMethod() method: 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 addSPPartnerProfileAuthnMethod() command:addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:Password", "BasicScheme") Exit the WLST environment:exit() After authentication via HTTP Basic Authentication, OIF/IdP would now issue an Assertion similar to (see that the AuthnContextClassRef was changed from PasswordProtectedTransport to Password): <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 ...>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://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:Password                </saml:AuthnContextClassRef>            </saml:AuthnContext>        </saml:AuthnStatement>    </saml:Assertion></samlp:Response> OAMLDAPPluginAuthnScheme as Authentication Scheme For this test, I will switch the default Authentication Scheme for the SP Partner Profile to OAMLDAPPluginAuthnScheme instead of BasicScheme. I will use the OIF WLST setSPPartnerProfileDefaultScheme() command and specify which scheme to be used as the default for the SP Partner Profile referenced by AcmeSP (which is saml20-sp-partner-profile in this case: getFedPartnerProfile("AcmeSP", "sp") ): 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 setSPPartnerProfileDefaultScheme() command:setSPPartnerProfileDefaultScheme("saml20-sp-partner-profile", "OAMLDAPPluginAuthnScheme") Exit the WLST environment:exit() The user will now be challenged via FORM defined in the OAMLDAPPluginAuthnScheme for AcmeSP. Contrarily to LDAPScheme and BasicScheme, the OAMLDAPPluginAuthnScheme is not mapped by default to any Federation Authentication Methods. As such, OIF/IdP will not be able to find a Federation Authentication Method and will set the method in the SAML Assertion to the OAM Authentication Scheme name. After authentication via FORM, OIF/IdP would issue an Assertion similar to (see the AuthnContextClassRef set to OAMLDAPPluginAuthnScheme): <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 ...>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://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> OAMLDAPPluginAuthnScheme                </saml:AuthnContextClassRef>            </saml:AuthnContext>        </saml:AuthnStatement>    </saml:Assertion></samlp:Response> Mapping OAMLDAPPluginAuthnScheme To add the OAMLDAPPluginAuthnScheme  to the Federation Authentication Method urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport mapping, I will execute the addSPPartnerProfileAuthnMethod() method: 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 addSPPartnerProfileAuthnMethod() command:addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "OAMLDAPPluginAuthnScheme") Exit the WLST environment:exit() After authentication via FORM, OIF/IdP would now issue an Assertion similar to (see that the method was changed from OAMLDAPPluginAuthnScheme to PasswordProtectedTransport): <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 ...>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://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> SAML 1.1 Test Setup In this setup, OIF is acting as an IdP and is integrated with a remote SAML 1.1 SP partner identified by AcmeSP. In this test, I will perform Federation SSO with OIF/IdP configured to: Use LDAPScheme as the Authentication Scheme Use OAMLDAPPluginAuthnScheme as the Authentication Scheme Map OAMLDAPPluginAuthnScheme to  the urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport Federation Authentication Method Use LDAPScheme as the Authentication Scheme Map LDAPScheme to  the urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport Federation Authentication Method LDAPScheme as Authentication Scheme Using the OOTB settings regarding user authentication in OAM, the user will be challenged via a FORM based login page based on the LDAPScheme. Also the default Federation Authentication Method mappings configuration maps only the urn:oasis:names:tc:SAML:1.0:am:password to LDAPScheme (also marked as the default scheme used for authentication), FAAuthScheme, BasicScheme and BasicFAScheme. After authentication via FORM, OIF/IdP would issue an Assertion similar to: <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:NameIdentifier ...>bob@oracle.com</saml:NameIdentifier>                <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> OAMLDAPPluginAuthnScheme as Authentication Scheme For this test, I will switch the default Authentication Scheme for the SP Partner to OAMLDAPPluginAuthnScheme instead of LDAPScheme. I will use the OIF WLST setSPPartnerDefaultScheme() command and specify which scheme to be used as the default for the SP 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 setSPPartnerDefaultScheme() command:setSPPartnerDefaultScheme("AcmeSP", "OAMLDAPPluginAuthnScheme") Exit the WLST environment:exit() The user will be challenged via FORM defined in the OAMLDAPPluginAuthnScheme for AcmeSP. Contrarily to LDAPScheme, the OAMLDAPPluginAuthnScheme is not mapped by default to any Federation Authentication Methods (in the SP Partner Profile). As such, OIF/IdP will not be able to find a Federation Authentication Method and will set the method in the SAML Assertion to the OAM Authentication Scheme name. After authentication via FORM, OIF/IdP would issue an Assertion similar to (see the AuthenticationMethod set to OAMLDAPPluginAuthnScheme): <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="OAMLDAPPluginAuthnScheme">            <saml:Subject>                <saml:NameIdentifier ...>bob@oracle.com</saml:NameIdentifier>                <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> Mapping OAMLDAPPluginAuthnScheme To map the OAMLDAPPluginAuthnScheme  to the Federation Authentication Method urn:oasis:names:tc:SAML:1.0:am:password for this SP Partner only, I will execute the addSPPartnerAuthnMethod() method: 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 addSPPartnerAuthnMethod() command:addSPPartnerAuthnMethod("AcmeSP", "urn:oasis:names:tc:SAML:1.0:am:password", "OAMLDAPPluginAuthnScheme") Exit the WLST environment:exit() After authentication via FORM, OIF/IdP would now issue an Assertion similar to (see that the method was changed from OAMLDAPPluginAuthnScheme to password): <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:NameIdentifier ...>bob@oracle.com</saml:NameIdentifier>                <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> LDAPScheme as Authentication Scheme I will now show that by defining a Federation Authentication Mapping at the Partner level, this now ignores all mappings defined at the SP Partner Profile level. For this test, I will switch the default Authentication Scheme for this SP Partner back to LDAPScheme, and the Assertion issued by OIF/IdP will not be able to map this LDAPScheme to a Federation Authentication Method anymore, since A Federation Authentication Method mapping is defined at the SP Partner level and thus the mappings defined at the SP Partner Profile are ignored The LDAPScheme is not listed in the mapping at the Partner level I will use the OIF WLST setSPPartnerDefaultScheme() command and specify which scheme to be used as the default for this SP 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 setSPPartnerDefaultScheme() command:setSPPartnerDefaultScheme("AcmeSP", "LDAPScheme") Exit the WLST environment:exit() After authentication via FORM, OIF/IdP would issue an Assertion similar to (see the AuthenticationMethod set to LDAPScheme): <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="LDAPScheme">            <saml:Subject>                <saml:NameIdentifier ...>bob@oracle.com</saml:NameIdentifier>                <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> Mapping LDAPScheme at Partner Level To fix this issue, we will need to add the LDAPScheme  to the Federation Authentication Method urn:oasis:names:tc:SAML:1.0:am:password mapping for this SP Partner only. I will execute the addSPPartnerAuthnMethod() method: Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the addSPPartnerAuthnMethod() command:addSPPartnerAuthnMethod("AcmeSP", "urn:oasis:names:tc:SAML:1.0:am:password", "LDAPScheme")Exit the WLST environment:exit() After authentication via FORM, OIF/IdP would now issue an Assertion similar to (see that the method was changed from LDAPScheme to password): <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:NameIdentifier ...>bob@oracle.com</saml:NameIdentifier>                <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> OpenID 2.0 In the OpenID 2.0 flows, the RP must request use of PAPE, in order for OIF/IdP/OP to include PAPE information. For OpenID 2.0, the configuration will involve mapping a list of OpenID 2.0 policies to a list of Authentication Schemes. The WLST command will take a list of policies, delimited by the ',' character, instead of SAML 2.0 or SAML 1.1 where a single Federation Authentication Method had to be specified. Test Setup In this setup, OIF is acting as an IdP/OP and is integrated with a remote OpenID 2.0 SP/RP partner identified by AcmeRP. In this test, I will perform Federation SSO with OIF/IdP configured to: Use LDAPScheme as the Authentication SchemeMap LDAPScheme to  the http://schemas.openid.net/pape/policies/2007/06/phishing-resistant and http://openid-policies/password-protected policies Federation Authentication Methods (the second one is a custom for this use case) LDAPScheme as Authentication Scheme Using the OOTB settings regarding user authentication in OAM, the user will be challenged via a FORM based login page based on the LDAPScheme. No Federation Authentication Method is defined OOTB for OpenID 2.0, so if the IdP/OP issue an SSO response with a PAPE Response element, it will specify the scheme name instead of Federation Authentication Methods After authentication via FORM, OIF/IdP would issue an SSO Response similar to: 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=LDAPScheme&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 Mapping LDAPScheme To map the LDAP Scheme to the http://schemas.openid.net/pape/policies/2007/06/phishing-resistant and http://openid-policies/password-protected policies Federation Authentication Methods, I will execute the addSPPartnerAuthnMethod() method (the policies will be comma separated): Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.shConnect to the WLS Admin server:connect()Navigate to the Domain Runtime branch:domainRuntime()Execute the addSPPartnerAuthnMethod() command:addSPPartnerAuthnMethod("AcmeRP", "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant,http://openid-policies/password-protected", "LDAPScheme")Exit the WLST environment:exit() After authentication via FORM, OIF/IdP would now issue an Assertion similar to (see that the method was changed from LDAPScheme to the two policies): 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+http%3A%2F%2Fopenid-policies%2Fpassword-protected&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 cover how OIF/IdP can be configured so that an SP can request a specific Federation Authentication Method to challenge the user during Federation SSO.Cheers,Damien Carru

In this article, I will provide examples on how to configure OIF/IdP to map OAM Authentication Schemes to Federation Authentication Methods, based on the concepts introduced in my previous entry. I...

Fed Authentication Methods in OIF / IdP

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 ...>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://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:NameIdentifier ...>bob@oracle.com</saml:NameIdentifier>                <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

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 in OIF / IdP

In this article, I will discuss about authentication when OIF acts as an IdP and how the server can be configured to use specific OAM Authentication Schemes to challenge the user. When OIF 11gR1 acting as an IdP and OAM 11g were integrated together, OIF was delegating the user authentication to OAM via the use of WebGate: OHS had to be installed in and configured to act as a reverse HTTP proxy for OIF WebGate had to be installed on OHS and registered with OAM OAM had to be configured to protect an OIF URL with An Authentication Policy An Authorization Policy Set up the OIF logout URL in OAM OIF had to be configured to use the OAM 11g Authentication Engine Enter the HTTP header containing the userID injected by WebGate Set up the OAM logout URL In OIF 11gR2 and OAM 11gR2, the two components are tightly integrated together: No initial setup is required to integrate the two products No WebGate/OHS is required for IdP authentication OIF/IdP can leverage any OAM Authentication Scheme Note: given the advanced nature of the configuration, OIF authentication setup can only be managed via OIF WLST commands. Enjoy the reading! Overview In the 11.1.2.2.0 or later release of OAM/OIF, the OIF J2EE Web Application and the OAM J2EE Web Application are contained in the same OAM J2EE EAR Application which is deployed in a standalone WLS instance. This deployment approach allows the two modules to internally forward the incoming user’s HTTP request from OIF to OAM and vice versa. This allows the OIF/IdP application to trigger a local OAM authentication operation that will challenge and identify the user. At runtime, when authentication is required by OIF/IdP in a Federation operation, OIF/IdP will: Internally forward the user to OAM Indicate to OAM which Authentication Scheme to use for user authentication 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 If the user needs to be challenged, OAM will do so based on the rules of the authentication scheme specified by OIF/IdP Once OAM has (optionally) authenticated the user and created a session, it will internally forward the user back to OIF/IdP with identity and session information OIF/IdP will resume the Federation operation it was performing Out of the box, OIF/IdP is configured to use the LDAPScheme as the OAM Authentication Scheme to challenge and identify users: this is set as the default global scheme for OIF/IdP. It is possible for an administrator: To set the global default OAM Authentication Scheme to be used to authenticate users. On an SP Partner Profile to set the OAM Authentication Scheme to be used to authenticate users for SP partners bound to this SP Partner Profile. If defined, this setting will take precedence over the global default OAM Authentication Scheme On an SP Partner to set the default OAM Authentication Scheme to be used to authenticate users for this SP partner. If defined, this setting will take precedence over the OAM Authentication Scheme defined in the SP Partner Profile referenced by this SP Partner or will take precedence over the global default OAM Authentication Scheme Testing Setup In this article, I will use the following testing environment: OIF/IdP One SAML 2.0 SP Partner called AcmeSP Another SAML 2.0 SP Partner called HRsp I will execute several test cases: Global Default Authentication: Both AcmeSP and HRsp will use the default SAML 2.0 SP Partner Profile No Authentication Scheme will be set at the SP Partner level No Authentication Scheme will be set at the SP Partner Profile level The global default authentication will be used as is (OOTB: LDAPScheme), and a Federation SSO operation will be performed The global default authentication will be set to BasicScheme (HTTP Basic Authentication), and a Federation SSO operation will be performed SP Partner Profile Authentication AcmeSP will use the default SAML 2.0 SP Partner Profile HRsp will use the another SAML 2.0 SP Partner Profile No Authentication Scheme will be set at the SP Partner level No Authentication Scheme will be set at the default SAML 2.0 SP Partner Profile level, but the new SAML 2.0 SP Partner Profile will be configured to use BasicScheme The global default authentication will be set to LDAPScheme A Federation SSO will be performed with AcmeSP A Federation SSO will be performed with HRsp SP Partner Authentication Both AcmeSP and HRsp will use the default SAML 2.0 SP Partner Profile The Authentication Scheme for the default SAML 2.0 SP Partner Profile will be set to BasicScheme The Authentication Scheme for the AcmeSP will be set to LDAPScheme The global default authentication will be set to LDAPScheme A Federation SSO will be performed with AcmeSP A Federation SSO will be performed with HRsp Step up Authentication via different Authentication Levels Both AcmeSP and HRsp will use the default SAML 2.0 SP Partner Profile The Authentication Scheme for the default SAML 2.0 SP Partner Profile will be set to BasicScheme The Authentication Scheme for the AcmeSP will be set to LDAPScheme The global default authentication will be set to LDAPScheme LDAPScheme will be configured to have its level set to 3 BasicScheme will be left unchanged with its level set to 2 Test #1: Federation SSO will be performed with AcmeSP User is challenged via LDAPScheme In the same browser, Federation SSO will be performed with HRsp The user won’t be challenged Test #2: Federation SSO will be performed with HRsp User is challenged via BasicScheme In the same browser, Federation SSO will be performed with AcmeSP User will be challenged via LDAPScheme The following sections, each one describing a test case, will be in a chronological order, with each section starting where the previous section left off. Note: If HTTP Basic Authentication will be used at the IdP, the WebLogic domain where OAM/OIF are running needs to be configured to not validate the HTTP Basic Authentication for unsecured resources. HTTP Basic Authentication By default, if a browser sends HTTP Basic Authentication credentials to OAM, the WLS server will attempt to validate those before letting OAM process the request: this can result in authentication failures, particularly if the WLS domain was not configured with WLS LDAP Authenticators for each Identity Store created in OAM. Note: even if the WLS domain was configured correctly to have a WLS LDAP Authenticator for each Identity Store created in OAM, this will result in two authentication operations, one by WLS, and the other one required by OAM to create an OAM session. It is possible to disable the automatic validation of HTTP Basic Authentication credentials sent to unsecured applications in the WLS domain where OAM is running. See section “Understanding BASIC Authentication with Unsecured Resources” of the Oracle Fusion Middleware Programming Security for Oracle WebLogic Server guide for more information. To disable the automatic validation of HTTP Basic Authentication credentials sent to unsecured applications in the WLS domain, execute the following steps: Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.sh Connect to the WLS Admin server:connect() Start an edit session:edit()startEdit() Navigate to the SecurityConfiguration node:cd('SecurityConfiguration') Navigate to the domain (replace DOMAIN_NAME with the name of the WLS domain where OAM is installed):cd('DOMAIN_NAME')   Set the EnforceValidBasicAuthCredentials setting to false to disable tomatic validation of HTTP Basic Authentication credentials sent to unsecured applications:set('EnforceValidBasicAuthCredentials','false') Save and activate the changes:save()activate() Restart the servers in the WLS domain for the changes to take effect Global Default Authentication The first step will be to create and configure SP Partners in OIF/IdP for SAML 2.0 SSO. After having set that up (see previous articles on how to do that), the list of SP Partners in OIF/IdP would look like: Performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user using the default global Authentication Scheme configured to be LDAPScheme OOTB: To switch the default global Authentication Scheme to BasicScheme, I will use the OIF WLST setIdPDefaultScheme() command and specify which scheme to be used as the default: 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 setIdPDefaultScheme() command:setIdPDefaultScheme("BasicScheme") Exit the WLST environment:exit() Performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will now result in the OIF/OAM server challenging the user using the OAM BasicScheme instead of LDAPScheme: To switch back the default global Authentication Scheme to LDAPScheme, perform the following operations: 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 setIdPDefaultScheme() command :setIdPDefaultScheme("LDAPScheme") Exit the WLST environment:exit() Performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user via the LDAPScheme. SP Partner Profile Authentication From the previous test cases, the setup is as: AcmeSP and HRsp exist in OIF/IdP The default global Authentication Scheme in OIF/IdP is LDAPScheme Both AcmeSP and HRsp are using the default SAML 2.0 SP Partner Profile To configure HRsp to use a new SP Partner Profile, execute the following commands (see my previous article in Partner Profiles for more information): 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() Create the new SP Partner Profile from the default SAML 2.0 SP Partner Profile:createFedPartnerProfileFrom("new-saml20-pp", "saml20-sp-partner-profile") Bind HRsp Partner to the new SP Partner Profile:setFedPartnerProfile("HRsp", "sp", "new-saml20-pp") Exit the WLST environment:exit() At this point, performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user via the LDAPScheme. To configure the new SP Partner Profile to have BasicScheme as the default Authentication Scheme, I will use the OIF WLST setSPPartnerProfileDefaultScheme() command: 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() Set the default Authentication Scheme for the new SP Partner Profile to BasicScheme:setSPPartnerProfileDefaultScheme("new-saml20-pp", "BasicScheme") Exit the WLST environment:exit() Now, performing Federation SSO with: AcmeSP will result in OIF/IdP challenging the user via the LDAPScheme. HRsp will result in OIF/IdP challenging the user via the BasicScheme. I will now bind HRsp back to the default SP Partner Profile, and then delete the SP Partner Profile I created in this test: 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() Bind HRsp Partner to the default SP Partner Profile:setFedPartnerProfile("HRsp", "sp", "saml20-sp-partner-profile") Delete the new SP Partner Profile:deleteFedPartnerProfile("new-saml20-pp") Exit the WLST environment:exit() After executing those commands, performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user via the LDAPScheme. SP Partner Authentication From the previous test cases, the setup is as: AcmeSP and HRsp exist in OIF/IdP The default global Authentication Scheme in OIF/IdP is LDAPScheme Both AcmeSP and HRsp are using the default SAML 2.0 SP Partner Profile To configure the default SAML 2.0 SP Partner Profile to use BasicScheme as the Authentication Scheme, perform the following operations: 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() Set the default Authentication Scheme for the new SP Partner Profile to BasicScheme:setSPPartnerProfileDefaultScheme("saml20-sp-partner-profile", "BasicScheme") Exit the WLST environment:exit() At this point, performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user via the BasicScheme. To configure the AcmeSP SP Partner to have LDAPScheme as the default Authentication Scheme, I will use the OIF WLST setSPPartnerDefaultScheme() command: 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() Set the default Authentication Scheme for the AcmeSP SP Partner to LDAPScheme:setSPPartnerDefaultScheme("AcmeSP", "LDAPScheme") Exit the WLST environment:exit() Now, performing Federation SSO with: AcmeSP will result in OIF/IdP challenging the user via the LDAPScheme. HRsp will result in OIF/IdP challenging the user via the BasicScheme. Step Up Authentication via Different Authn Levels From the previous test cases, the setup is as: AcmeSP and HRsp exist in OIF/IdP The default global Authentication Scheme in OIF/IdP is LDAPScheme Both AcmeSP and HRsp are using the default SAML 2.0 SP Partner Profile The default SAML 2.0 SP Partner Profile is configured with the default Authentication Scheme set to BasicScheme The AcmeSP SP Partner is configured with the default Authentication Scheme set to LDAPScheme At this point, performing Federation SSO with: AcmeSP will result in OIF/IdP challenging the user via the LDAPScheme. HRsp will result in OIF/IdP challenging the user via the BasicScheme. OOTB, the Authentication Level for both LDAPScheme and BasicScheme is set to 2. To change the Authentication Level of the LDAPScheme to 3, perform the following operations: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Authentication Schemes Click Search and select LDAPScheme Set the Authentication Level to 3 Apply After those changes, if the user is already authenticated at OAM and that the user performs a Federation SSO operation with OIF/IdP, OIF/OAM will ensure that the scheme which was used to authenticate the user in the first place has a level higher or equal to the scheme configured for the current SP Partner with which Federation SSO is exercised. For example: If the user is first authenticated via LDAPScheme, it won’t be re-challenged when a second Federation SSO operation is performed with the default Authentication Scheme for that second flow being BasicScheme: Federation SSO is started with AcmeSP Partner User is challenged by OAM/OIF via LDAPScheme OIF/IdP issues an Assertion and redirects the user to AcmeSP In the same browser, Federation SSO is started with HRsp OAM/OIF won’t challenge the user, because the user is already authenticated, the session hasn’t timed out and the level of the scheme used to create the session (which was 3 for LDAPScheme) is higher or equal than the default scheme configured for this current Federation SSO (which is 2 for BasicScheme) OIF/IdP issues an Assertion and redirects the user to HRsp If the user is first authenticated via BasicScheme, it will be re-challenged when a second Federation SSO operation is performed with the default Authentication Scheme for that second flow being LDAPScheme: Federation SSO is started with HRsp Partner User is challenged by OAM/OIF via BasicScheme OIF/IdP issues an Assertion and redirects the user to HRsp In the same browser, Federation SSO is started with AcmeSP OAM/OIF will challenge the user, because the user is already authenticated, the session hasn’t timed out but the level of the scheme used to create the session (which was 2 for BasicScheme) is lower than the default scheme configured for this current Federation SSO (which is 3 for LDAPScheme) OIF/IdP issues an Assertion and redirects the user to AcmeSP In the next article, I will discuss how OIF/IdP can be configured to map Federation Authentication Methods to OAM Authentication Schemes, both when processing an Authn Request (SP requests a specific Federation Authentication Method) and when sending an Assertion (IdP sets the Federation Authentication Method).Cheers,Damien Carru

In this article, I will discuss about authentication when OIF acts as an IdP and how the server can be configured to use specific OAM Authentication Schemes to challenge the user. When OIF 11gR1 acting...

Partner Profiles in OIF

In this article, I will discuss about the concept of Partner Profile in the OIF configuration. During any Federation runtime operation between OIF (as an IdP or SP) and remote partners, numerous configuration properties are evaluated that will affect how OIF will execute the operation. Some of the configuration parameters driving the protocol exchange are specific to the partner with which OIF is interacting (like how the NameID should be populated if OIF acts as a SAML 2.0 IdP), while others can be common to a group of partners (like whether or not to sign SAML 2.0 Assertions when OIF acts as an IdP). Instead of having each partner entry in the OIF configuration containing all the OIF parameters required to perform the Federation runtime operations, OIF makes use of a Partner Profile which: Contains a set of settings that are common to all partners referencing that partner profile Is specific to A type, either IdP or SP A protocol: SAML 2.0, SAML 1.1 or OpenID 2.0 A Partner Profile in OIF typically contains configuration settings that are generally not changed often and that are considered advanced. For the day-to-day operations, the administration capabilities provided in the OAM Administration Console or via the OIF WLST commands are enough for most cases. For advanced cases requiring configuration changes, an administrator would have the choice to: Either update the Partner configuration entry, so changes would only apply to the partner Or update the Partner Profile entry, so changes would apply to all partners bound to the Partner Profile Important note: given the advanced nature of the configuration, Partner Profiles can only be managed via OIF WLST commands. Default Partner Profiles Out of the box, OIF defines default Partner Profiles which contain the default settings for their respective Federation protocols and service types. The default settings are tailored for the common use cases encountered in production deployments today, and as such you would not need to change those except for specific use cases. After installation, the following Partner Profiles will be defined in the OIF configuration: saml20-idp-partner-profile: Protocol: SAML 2.0 Type: Partner Profile for IdP partners saml20-sp-partner-profile: Protocol: SAML 2.0 Type: Partner Profile for SP partners saml11-idp-partner-profile: Protocol: SAML 1.1 Type: Partner Profile for IdP partners saml11-sp-partner-profile: Protocol: SAML 1.1 Type: Partner Profile for SP partners openid20-idp-partner-profile: Protocol: OpenID 2.0 Type: Partner Profile for IdP/OP partners openid20-sp-partner-profile: Protocol: OpenID 2.0 Type: Partner Profile for SP/RP partners WLST Commands Settings contained in a Partner Profile entry are deemed advanced properties, and as such as only manageable via OIF WLST commands, while basic settings changes or day-to-day operations can be performed either via the OAM Administration Console or via OIF WLST commands. In the next sections, I will show how to use the various OIF WLST Partner Profile commands to: List all the Partner Profiles List the Partners bound to a specific Partner Profile List the Partner Profile used by a Partner Display the content of a Partner Profile Create a new Partner Profile Update a Partner Profile: in this case I will change the hashing algorithm used in Digital Signatures in outgoing signed messages to SHA-256 Bind the Partner Profile to a Partner Delete a Partner Profile It is sometimes desirable to create new Partner Profile entries when several partners have a common set of use cases which differ from the configuration defined in the Partner Profile entry they are bound to. Instead of having each Partner override a setting (for example signing messages using SHA-256 digest algorithm instead of the default SHA-1 defined in their Partner Profile entries), the better approach consists in: Creating a new Partner Profile by making a copy of the Partner Profile currently used by the Partner Set the Partner to use the new Partner Profile Modify the Partner Profile For more information on the OIF WLST commands, please refer to the Oracle documentation. WLST Environment I will assume that you are already in the WLST environment and connected using: 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() Listing Partner Profiles The listFedPartnerProfiles() WLST command will list all Partner Profiles currently present in OIF, and will display: Name Type (SP or IdP) Protocol Version: SAML 2.0, SAML 1.1 or OpenID 2.0 For example, an execution of the command would display the following: wls:/test_domain/domainRuntime> listFedPartnerProfiles()Partner Profile ID  |  Type  |  Protocol Versionsaml20-sp-partner-profile  |  sp  |  saml20saml20-idp-partner-profile  |  idp  |  saml20saml11-sp-partner-profile  |  sp  |  saml11saml11-idp-partner-profile  |  idp  |  saml11openid20-sp-partner-profile  |  sp  |  openid20openid20-idp-partner-profile  |  idp  |  openid20 Listing Partners for a Specific Partner Profile The listFedPartnersForProfile() command will list all partners bound to the Partner Profile specified as a parameter. Executing the command to display all partners referencing the saml20-sp-partner-profile Partner Profile (which is the default OOTB profile for SAML 2.0 SP Partners) would display the following: wls:/test_domain/domainRuntime> listFedPartnersForProfile("saml20-sp-partner-profile")adc00peqOffice365ACME-ADFS Listing Partner Profile for a Specific Partner The getFedPartnerProfile() command will display the Partner Profile used by the Partner and the partner type specified as parameters (the partner type is either idp or sp) Executing the command to display the Partner Profile referenced by the ACME-ADFS SP Partner would display the following: wls:/test_domain/domainRuntime> getFedPartnerProfile("ACME-ADFS", "sp")saml20-sp-partner-profile Displaying the Content of a Partner Profile The displayFedPartnerProfile() WLST command will display on the command line the settings defined in the entry specified as a parameter. Executing the command to show the Partner Profile would display the following: wls:/test_domain/domainRuntime> displayFedPartnerProfile("saml20-sp-partner-profile")includecertinsignature=0nameidqualifier=forceconsent=0authnmethodmappings={urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aac%3Aclasses%3APasswordProtectedTransport=LDAPScheme-1,OAM10gScheme-0,FAAuthScheme-1,BasicScheme-1,BasicFAScheme-1}sendsignedrequestquery=1forceconsenturl=sendencryptednameid=0sendsignedresponsequery=1setconsentenabled=0sessionattributeforceauthn=0defaultauthnrequestnameidformat=orafed-emailaddressversion=saml20requesttimeout=2000audiencerestrictionenabled=1setconsentvalue=sendsignedresponsesoap=1allowfederationcreation=1sendsignedresponseassertionpost=0reauthenticate=3600description=sendattribute=1defaultencryptionmethod=http://www.w3.org/2001/04/xmlenc#aes128-cbcrequiresignedrequestquery=0requiresignedresponsepost=0audiencerestrictionvalue=sendsignedrequestsoap=1sendsignedrequestpost=1sendencryptedattribute=0partnerprofiletype=sprequiresignedresponsesoap=0requiresignedrequestpost=0requiresignedresponsequery=0partnerprofileid=saml20-sp-partner-profilesendsignedresponsepost=1requiresignedrequestsoap=0sendsignedassertion=1sendsignedresponseassertionsoap=0assertionvalidityinterval=300 Creating a new Partner Profile In this section, I will show how to create a new Partner Profile from an existing one, by using the createFedPartnerProfileFrom() method which takes as arguments: The name of the new Partner Profile The name of the Partner Profile to copy from Executing the command to create a new SAML 2.0 SP Partner Profile based on the OOTB one would display the following: wls:/test_domain/domainRuntime> createFedPartnerProfileFrom("new-saml20-pp", "saml20-sp-partner-profile")Command was successful. Updating a Partner Profile In this section, I will show an example of a WLST configuration change command involving a Partner Profile. As mentioned previously, I created this Partner Profile for Partners for which SHA-256 needs to be used in outgoing Digital Signatures. I will use the configureFedDigitalSignature() command to configure the new Partner Profile called  new-saml20-pp to use SHA-256. The command takes the Partner Profile name, the profile type as well as the hashing algorithm to use as parameters: wls:/test_domain/domainRuntime> configureFedDigitalSignature(partnerProfile="new-saml20-pp", partnerType="sp", algorithm="SHA-256")Command was successful. Binding a Partner to a Partner Profile Once the new Partner Profile is created (and configured) existing Partners can be bound to it. In my example, three SP Partners are listed: adc00peq Office365 ACME-ADFS I only want adc00peq and ACME-ADFS to be switched to the new Partner Profile. I will use the setFedPartnerProfile() command and specify the Partner, its type and the new Partner Profile to use: wls:/test_domain/domainRuntime> setFedPartnerProfile("adc00peq", "sp", "new-saml20-pp")Command was successful.wls:/test_domain/domainRuntime> setFedPartnerProfile("ACME-ADFS", "sp", "new-saml20-pp")Command was successful. Listing the partners bound to the new profile would show adc00peq and ACME-ADFS, while listing the partners to the saml20-sp-partner-profile profile would only show Office365: wls:/test_domain/domainRuntime> listFedPartnersForProfile("new-saml20-pp")adc00peqACME-ADFSwls:/test_domain/domainRuntime> listFedPartnersForProfile("saml20-sp-partner-profile")Office365 In the example, OIF/IdP would now sign using the SHA-256 digest algorithm for adc00peq and ACME-ADFS, while it would still use SHA-1 for the Office365 Deleting a Partner Profile Partner Profiles can be deleted via the deleteFedPartnerProfile() which takes the name of the profile as a parameter, but prior executing the command, you must ensure that no Partner entries are currently bound to this Partner Profile. If I attempt to delete the new-saml20-pp Partner Profile while it is still referenced by the adc00peq and ACME-ADFS SP Partners, the method will return an error: wls:/test_domain/domainRuntime> deleteFedPartnerProfile("new-saml20-pp")The Federation Partner Profile is in use by a Partner First, the two partners will need to be switched back to another Partner Profile (saml20-sp-partner-profile in this example), and then the deleteFedPartnerProfile() can be invoked: wls:/test_domain/domainRuntime> setFedPartnerProfile("adc00peq", "sp", "saml20-sp-partner-profile")Command was successful.wls:/test_domain/domainRuntime> setFedPartnerProfile("ACME-ADFS", "sp", "saml20-sp-partner-profile")Command was successful.wls:/test_domain/domainRuntime> deleteFedPartnerProfile("new-saml20-pp")Command was successful. In the next article, I will discuss about authentication when OIF acts as an IdP and how the server can be configured to use specific OAM Authentication Schemes to challenge the user.Cheers,Damien Carru

In this article, I will discuss about the concept of Partner Profile in the OIF configuration. During any Federation runtime operation between OIF (as an IdP or SP) and remote partners, numerous...

Integrating Office 365 with OIF/IdP

This is a continuation of my previous article where I will configure OIF (11.1.2.2.0 or later) as an IdP with Office 365 for Federation SSO using the SAML 2.0 protocol. Be sure to have read the article about pre-requisites. The integration will cover: Browser Federation SSO integration: this is the flow the user will exercise when accessing the www.office365.com resources via a browser: The www.office365.com will prompt the user to enter its email address The server will detect that Federation SSO should be used for that domain and will start a Federation SSO flow the OIF/IdP OIF/IdP will challenge the user, create a SAML Assertion and redirect the user to www.office365.com www.office365.com will grant access to the user ActiveSync mail integration: in this flow, the user will use a mail application configured for Office 365 When the mail application is started, it will send the user’s credentials (email address and IdP password) to Office 365 www.office365.com will make a direct connection over SSL to the IdP and will use the SAML 2.0 ECP protocol to send a SAML AuthnRequest and the user’s credentials via HTTP Basic Authentication The OIF/IdP will validate those credentials and return a SAML Assertion via the ECP protocol Office 365 will grant access to the mail application It is important to note that integration with Office 365 for non SAML 2.0 components will not work, such as: Lync clients OWA Mobile Apps This article is based on: The testing performed by Thomas Guo from Oracle and myself The Microsoft article regarding SAML 2.0 support for Office 365 and more specifically the technical document listing steps required to configure Office 365 (user management and Federation trust establishment): Microsoft Blog Technical document describing how to configure Office 365 Testing Environment For this test integration, I will use the following approach: User alice at OAM/OIF: Username (uid attribute): alice.appleton Email address (mail attribute): alice.appleton@acme.com First name (givenname attribute): Alice Last name (sn attribute): Appleton User alice at Office 365 (see the Microsoft technical document on more information on how to create a user in Azure AD): UserPrincipalName: alice.appleton@acme.com ImmutableId: alice.appleton DisplayName: Alice Appleton FirstName: Alice LastName: Appleton UsageLocation: US Federation agreement: SAML 2.0 NameID format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent LDAP attribute used to populate SAML 2.0 NameID value: uid (because the NameID must match the ImmutableId) SAML Attribute contained in the SAML Assertion Name: IDPEmail LDAP Attribute used to populate this attribute value: mail (because the attribute value must match the UserPrincipalName) Office 365 specifics: The domain name will be acme.com The protocol used will be SAMLP ActiveSync mail application will be supported OIF Configuration Setting up Office 365 as an SP in OIF/IdP will consist in: Creating an SP Attribute Profile in order to send the IDPEmail attribute containing the mail attribute Creating an SP partner for Office 365 and bind it to the new SP Attribute Profile Updating the Office 365 SP Partner configuration for SHA-1 hashing algorithm in signatures Inclusion of OIF’s signing certificate in outgoing SAML messages HTTP Basic Auth for ActiveSync mail integration Office 365 Configuration Please refer to the following Microsoft information when reading this section: Microsoft  Blog Technical document describing how to configure Office 365 Windows Powershell Ensure that the Windows Powershell tools are installed on the computer from which you will connect to Office 365 for administration purposes. Provisioning OIF/IdP as a Partner in Office 365 Top create OIF as an IdP partner for the acme.com domain in Office 365, perform the following steps: Connect to Office 365 as the administrator for acme.comConnect-MsolService Set the following environment variables (the data used is the one retrieved from the pre-requisites section; note that the string for $idpSigningCert is on the same line as the $idpSigningCert =, and that it is a single line): $domainName = "acme.com" $BrandName - "ACME IdP" $browserSSOLoginURL = "https://acme.com/oamfed/idp/samlv20" $ecpSSOURL = "https://acme.com/oamfed/idp/soap" $logoutURL = "https://acme.com/oamfed/idp/samlv20" $issuerProviderID = "https://acme.com/oam/fed" $idpSigningCert = "MIIB+DCCAWGgAwIBAgIBCjANB......oInVUbGTBDMfqmW5iZ/wjpzItg==" $ssoProtocol = "SAMLP" Execute the following command using the above variables:Set-MsolDomainAuthentication -DomainName $domainName -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $browserSSOLoginURL -ActiveLogOnUri $ecpSSOURL -SigningCertificate $idpSigningCert -IssuerUri $issuerProviderID -LogOffUri $logoutURL -PreferredAuthenticationProtocol $ssoProtocol OIF Configuration SP Attribute Profile To create a new SP Attribute Profile that will be set up to send the SAML IDPEmail Attribute containing the user’s UPN value, perform the following operations: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the “Service Provider Attribute Profiles” tab Click on the “Create SP Attribute Profile” button Enter a name for the new profile (for example Office365-attr-profile) In the Attribute Mapping section, click Add Enter the following information: Message Attribute Name: IDPEmail Value: enter the LDAP user attribute containing the user’s UPN in the directory used by OAM (in this example: user -> attr -> mail) Always send: checked Click OK The Attribute Profile will be shown: Click Save Office 365 SP Partner To add Office 365 as an SP partner in OIF, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the “Create Service Provider Partner” button In the Create screen: Enter a name for the partner (for example Office365) Select SAML 2.0 as the Protocol Click Load Metadata and upload the SAML 2.0 Metadata file for the Office 365 Select Persistent as the NameID format Enter the LDAP user attribute that contains the user’s ImmutableId value (in this example, uid) Select the SP Attribute Profile that was previously created (in this example Office365-attr-profile) Click Save SHA-1 Hash Algorithm for Digital Signatures To configure OIF to use SHA-1 for signatures for the Office 365 SP partner, execute the following steps: 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 configureFedDigitalSignature() command:configureFedDigitalSignature(partner="PARTNER_NAME", partnerType="sp", algorithm="SHA-256/SHA-1") Replace PARTNER_NAME with the name of the added partner An example would be:configureFedDigitalSignature(partner="Office365", partnerType="sp”, algorithm="SHA-1") Exit the WLST environment:exit() OIF’s Signing Certificate in XML Digital Signatures To configure OIF so that the Federation server will include its X.509 signing certificate in all outgoing signed SAML messages for the Office 365 SP partner, execute the following steps: 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 updatePartnerProperty() command:updatePartnerProperty("PARTNER_NAME", "sp", "includecertinsignature", "true", "boolean") Replace PARTNER_NAME with the name of the added partner An example would be:updatePartnerProperty("Office365", "sp", "includecertinsignature", "true", "boolean") Exit the WLST environment:exit() HTTP Basic Auth for ActiveSync Mail Integration In the SAML 2.0 ECP flow, the Office 365 server will make a direct connection to OIF/IdP over SOAP over HTTPS and will post a SAML AuthnRequest message. Alongside the SOAP request, the HTTP request will contain the user’s credentials as part of the HTTP Basic Authentication headers. OIF/IdP must be configured to use an OAM HTTP Basic Authentication scheme to validate those credentials. Also this operation must not result in an OAM session to be created, since this is rather a credential validation operation initiated by the Office 365 server, and not the user involved with OAM/OIF. For those reasons, OIF/IdP must be configured to use a scheme based on: BASIC mode With the challenge parameters containing the CookieLessMode=true entry The BasicSessionlessScheme can be used for this flow. Also, OIF must be configured to send "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" as a SAML 2.0 Authentication Method when the client is authenticated via the BasicSessionlessScheme. To configure OIF to use HTTP Basic Authentication in the SAML 2.0 ECP flow, execute the following steps: 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 setSPPartnerAlternateScheme() command to instruct OIF to use BasicSessionlessScheme :setSPPartnerAlternateScheme(PARTNER_NAME, "true", httpHeaderName="X-MS-Client-Application", httpHeaderExpression=".*Microsoft.Exchange..*", authnScheme="BasicSessionlessScheme") Replace PARTNER_NAME with the name of the added partner An example would be:setSPPartnerAlternateScheme("Office365", "true", httpHeaderName="X-MS-Client-Application", httpHeaderExpression=".*Microsoft.Exchange..*", authnScheme="BasicSessionlessScheme") Retrieve the OIF Fed partner profile used by the Office 365 SP partner in OIF (see next article for more information on Partner Profiles):getFedPartnerProfile(PARTNER_NAME "sp") Replace PARTNER_NAME with the name of the added partner An example would be:getFedPartnerProfile("Office365", "sp") Write down the returned value Execute the addSPPartnerProfileAuthnMethod() command to instruct OIF to send "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"  as the SAML 2.0 Authentication Method when the client is authenticated via BasicSessionlessScheme:addSPPartnerProfileAuthnMethod(PARTNER_PROFILE, "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "BasicSessionlessScheme") Replace PARTNER_PROFILE with the value retrieved in the earlier step An example would be:addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "BasicSessionlessScheme") Exit the WLST environment:exit() Testing Browser SSO To test the Browser SSO flows: Open a browser Go to http://office365.com Click Sign In Enter the user’s email address Execute the following steps: Click Next Office 365 will attempt to locate your Office 365 domain based on the suffix of the email address Once the domain has been located, Office 365 will trigger a Federation SSO flow to redirect you to OIF / IdP for authentication Execute the following steps: At OIF / IdP enter username/password (depending on the Authentication scheme used to authenticate Federated users, LDAPScheme in this example) Click login OIF/IdP will validate the credentials, create a SAML 2.0 Assertion and redirects the user back to Office 365 where the user will be granted access: A sample SAML 2.0 Assertion sent by OIF / IdP to Office 365 would look like: <samlp:Response ... Destination="https://login.microsoftonline.com/login.srf" ID="id--eBpq-cnpGfrWXMpBIjxN7QPQKa6WTVtnuZZr0Qe" InResponseTo="_d111d2a7-3475-4bc2-928f-34b83a4a0f64" IssueInstant="2014-01-18T16:58:05Z" Version="2.0">  <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://acme.com/oam/fed</saml:Issuer>  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>  <saml:Assertion ID="id-nTZcRuTaECKj2X9wzUTn7e-CknyECbGljTSo1T70" IssueInstant="2014-01-18T16:58:05Z" Version="2.0">    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://acme.com/oam/fed</saml:Issuer>    <dsig:Signature>      <dsig:SignedInfo>        <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>        <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>        <dsig:Reference URI="#id-nTZcRuTaECKj2X9wzUTn7e-CknyECbGljTSo1T70">          <dsig:Transforms>            <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>            <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>          </dsig:Transforms>          <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>          <dsig:DigestValue>6iKaxdO74Xi5eRnv0X7nsmN/y10=</dsig:DigestValue>        </dsig:Reference>      </dsig:SignedInfo>      <dsig:SignatureValue>WYCBhIgPLafDeXroMSME80/QM...K/sNsI=</dsig:SignatureValue>      <dsig:KeyInfo>        <dsig:X509Data>          <dsig:X509Certificate>MIIB+DCCAWGgA...plaoMZLcRoInVUbGTBDMfqmW5iZ/wjpzItg==</dsig:X509Certificate>        </dsig:X509Data>      </dsig:KeyInfo>    </dsig:Signature>    <saml:Subject>      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://acme.com/oam/fed" SPNameQualifier="urn:federation:MicrosoftOnline">alice.appleton</saml:NameID>      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData InResponseTo="_d111d2a7-3475-4bc2-928f-34b83a4a0f64" NotOnOrAfter="2014-01-18T17:03:05Z" Recipient="https://login.microsoftonline.com/login.srf"/></saml:SubjectConfirmation>    </saml:Subject>    <saml:Conditions NotBefore="2014-01-18T16:58:05Z" NotOnOrAfter="2014-01-18T17:03:05Z">      <saml:AudienceRestriction>        <saml:Audience>urn:federation:MicrosoftOnline</saml:Audience>      </saml:AudienceRestriction>    </saml:Conditions>    <saml:AuthnStatement AuthnInstant="2014-01-18T16:58:05Z" SessionIndex="id-IM-SvfoQa8uVVtSmN-lrdOfgEVKFJHF8AhmIDzj-" SessionNotOnOrAfter="2014-01-18T17:58:05Z">      <saml:AuthnContext>        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>      </saml:AuthnContext>    </saml:AuthnStatement>    <saml:AttributeStatement>      <saml:Attribute Name="IDPEmail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">        <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">alice.appleton@acme.com</saml:AttributeValue>      </saml:Attribute>    </saml:AttributeStatement>  </saml:Assertion></samlp:Response> ActiveSync Mail Application For this test, I will add an Exchange email account on an iPhone. During the setup, the iPhone mail application will send the email address and password to Office 365 mail server, which will extract the user identifier from the email address and perform the SAML 2.0 ECP protocol with HTTP Basic Authentication. Note: a similar flow would be exercised if the setup involved an Outlook Desktop application instead of the iPhone mail native application. Perform the following steps to set up the iPhone with Office 365: Go to Settings Go to Mail Add Account Select Exchange Perform the following steps: Enter the email address (alice.appleton@acme.com in this example) Password at OAM/OIF for the user (password for alice.appleton user; remember that the identifier will be used as the HTTP Basic Authentication username, alice.appleton in this example) Perform the following steps: Click Next The mail application will send the user account information to Office 365 mail server Office 365 mail server will interact with OIF / IdP via the SAML 2.0 ECP protocol to validate the data, with the user identifier and password sent via HTTP Basic Authentication to OIF / IdP Upon successful validation, the iPhone will show: After showing the successful validation, the iPhone will display a screen allowing the user to select which feature to enable. After selecting the features, save: the account will have been set up. In the next article, I will discuss about an OIF configuration item called Partner Profiles.Cheers,Damien Carru

This is a continuation of my previous article where I will configure OIF (11.1.2.2.0 or later) as an IdP with Office 365 for Federation SSO using the SAML 2.0 protocol. Be sure to have read the article...

Integrating Office 365 with OIF/IdP Pre-Requisites

In the next two articles, I will describe how to integrate OIF (11.1.2.2.0 or later) as an IdP with Office 365 for Federation SSO using the SAML 2.0 protocol. The integration will cover: Browser Federation SSO integration: this is the flow the user will exercise when accessing the www.office365.com resources via a browser: The www.office365.com will prompt the user to enter its email address The server will detect that Federation SSO should be used for that domain and will start a Federation SSO flow the OIF/IdP OIF/IdP will challenge the user, create a SAML Assertion and redirect the user to www.office365.com www.office365.com will grant access to the user ActiveSync mail integration: in this flow, the user will use a mail application configured for Office 365 When the mail application is started, it will send the user’s credentials (email address and IdP password) to Office 365 www.office365.com will make a direct connection over SSL to the IdP and will use the SAML 2.0 ECP protocol to send a SAML AuthnRequest and the user’s credentials via HTTP Basic Authentication The OIF/IdP will validate those credentials and return a SAML Assertion via the ECP protocol Office 365 will grant access to the mail application It is important to note that integration with Office 365 for non SAML 2.0 components will not work, such as: Lync clients OWA Mobile Apps This article is based on: The testing performed by Thomas Guo from Oracle and myself The Microsoft article regarding SAML 2.0 support for Office 365 and more specifically the technical document listing steps required to configure Office 365 (user management and Federation trust establishment): Microsoft Blog. Technical document describing how to configure Office 365. Overview In order to integrate with Office 365 using the SAML 2.0 protocol, OAM/OIF must be configured to use HTTPS/SSL as their endpoints with SSL certificates issued by well known CAs (if ActiveSync mail integration is required). Failure to do so might result in Office 365 not accepting the OIF SAML 2.0 Metadata when establishing Federation Trust. Office 365 expects that all SAML messages will be signed using the SHA-1 digest algorithm. As such, OIF/IdP must be configured to use SHA-1, otherwise Office 365 SP will return an error if SHA-256 is used. Also, Office 365 requires the IdP’s signing certificate to be included in the signed SAML Assertion: so OIF will need to be configured to include it in all outgoing signed message for Office 365. If HTTP Basic Authentication will be used at the IdP (as it is required for the ActiveSync mail integration), the WebLogic domain where OAM/OIF are running needs to be configured to not validate the HTTP Basic Authentication for unsecured resources. In order to establish trust between the two Federation servers, the following data must be retrieved: The Office 365 SP SAML 2.0 Metadata. Since Office 365 does not support yet SAML 2.0 Metadata consumption, the following information must be collected: The OIF IdP signing certificate in Base64 encoded format The OIF IdP Issuer value The OIF IdP SSO and Logout URLs Finally in order to be able to establish Federation trust, the following needs to occur: For a given user, both Office 365 and the directory used by OAM/OIF must have an account for that user The user global unique ID (or ImmutableId) and the email address (or UserPrincipalName) used in the Office 365 account must be set in the user account at OAM/OIF For the ActiveSync mail integration, the identifier in the email address (or UserPrincipalName) used by Office 365 must be the username used for HTTP Basic Authentication at OAM/OIF Enabling SSL Important note: the SSL certificate used to enable SSL for OAM must have been issued by well known CAs, since the Office 365 server will attempt to make a direct connection to the OAM/OIF server for the ActiveSync use case. There are several ways to enable SSL on the public endpoints for OAM/OIF: If a load balancer is fronting OAM/OIF, SSL/HTTPS can be enabled/configured on the load balancer If OHS is fronting OAM/OIF, OHS will be configured for SSL If no component is fronting OAM/OIF, then the WLS server where OAM is running can be configured for SSL/HTTPS Once the component (Load balancer, OHS or WLS) has been configured for SSL, the OAM configuration needs to be updated to reference the new endpoint as its public URL: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Access Manager Settings Set the OAM Server Host to the hostname of the public endpoint Set the OAM Server Post to the SSL port of the public endpoint Set the OAM Server Protocol to https Apply Note: after making those changes, retrieving the OIF SAML 2.0 Metadata will contain the new https URLs HTTP Basic Authentication By default, if a browser sends HTTP Basic Authentication credentials to OAM, the WLS server will attempt to validate those before letting OAM process the request: this can result in authentication failures, particularly if the WLS domain was not configured with WLS LDAP Authenticators for each Identity Store created in OAM. Note: even if the WLS domain was configured correctly to have a WLS LDAP Authenticator for each Identity Store created in OAM, this will result in two authentication operations, one by WLS, and the other one required by OAM to create an OAM session. It is possible to disable the automatic validation of HTTP Basic Authentication credentials sent to unsecured applications in the WLS domain where OAM is running. See section "Understanding BASIC Authentication with Unsecured Resources" of the Oracle Fusion Middleware Programming Security for Oracle WebLogic Server guide for more information. To disable the automatic validation of HTTP Basic Authentication credentials sent to unsecured applications in the WLS domain, execute the following steps: Enter the WLST environment by executing:$IAM_ORACLE_HOME/common/bin/wlst.sh Connect to the WLS Admin server:connect() Start an edit session:edit()startEdit() Navigate to the SecurityConfiguration node:cd('SecurityConfiguration') Navigate to the domain (replace DOMAIN_NAME with the name of the WLS domain where OAM is installed):cd('DOMAIN_NAME')  Set the EnforceValidBasicAuthCredentials setting to false to disable tomatic validation of HTTP Basic Authentication credentials sent to unsecured applications:set('EnforceValidBasicAuthCredentials','false') Save and activate the changes:save()activate() Restart the servers in the WLS domain for the changes to take effect SAML 2.0 Metadata, Certificate and Issuer To download the SAML 2.0 Metadata from the Office 365 SP server: Open a browser Go to the Azure / Office 365 Metadata publishing service:https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml Save the Metadata locally using the Save As button in the browser The OIF IdP Signing Certificate must be provided as a Base64 encoded string to the Windows Powershell commands, as a single string with no spaces/line-breaks. To retrieve the OIF IdP Signing Certificate, perform the following operations to determine which keyID entry is used to sign outgoing SAML messages: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration  -> Federation Settings Note the keyID of the Signing Key for SAML signature operations, in the Signing Key field Perform the following steps to retrieve the certificate for that keyID entry: Open a browser Go to the following URL (replace KEYENTRY_ID by the keyID name retrieved in the previous step):http://oam-runtime-host:oam-runtime-port/oamfed/idp/cert?id=<KEYENTRY_ID> Save the certificate in a text file. Open the file with your favorite text editor The content of the file will look like:-----BEGIN CERTIFICATE-----MIIB+DCCAWGgAwIBAgIBCjANBgkqhkiG9w0BAQQFADAhMR8wHQYDVQQDExZhZGMwMHBjYy51cy5vcmFjbGUuY29tMB4XDTE0MDMwNDE5MjAzMloXDTI0MDMwMTE5MjAzMlowITEfMB0GA1UEAxMWYWRjMDBwY2MudXMub3JhY2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAkQOdZCmoOQRuxSvI/74bjnUPq7u7qiGbmaN1D5TBJaM+j5XRixEUI3pidaxlbykaraqVBMJpXJ6ua0QWectv6SdzuqcvH8C5el06NxTsfB6pcvxHGXVAbAvtGr2tOPSL+5HaFQoATpiY3HugTnJfjmHRfOqIo8nUMek6zCtvrKUCAwEAAaNAMD4wDAYDVR0TAQH/BAIwADAPBgNVHQ8BAf8EBQMDB9gAMB0GA1UdDgQWBBQ/7yJbGCbbAnaLEi4ReLwLlvSxJTANBgkqhkiG9w0BAQQFAAOBgQBrMb2i6zcChhVM7a9VVgBr8xljBsPxVWCAYNUYaoyUj9VkD4CpFF9hVX0CpceoSBTiyMQp3sg0FAYz1PGfjrq7uFEq9iTCwa5J/7k/VSOLKd3IDqzz7w0ZERksgp3OOqOct/wB/wQplaoMZLcRoInVUbGTBDMfqmW5iZ/wjpzItg==-----END CERTIFICATE----- Remove the first line (-----BEGIN CERTIFICATE-----), remove the last line (-----END CERTIFICATE-----), and modify the rest of the file to remove the line breaks. The result should be a single line file (the content was shortened):MIIB+DCCAWGgAwIBAgIBCjANBg....InVUbGTBDMfqmW5iZ/wjpzItg== Save the file. This line will be provided as an input to the Windows Powershell command. Perform the following steps to retrieve the IdP’s Issuer / Provider ID: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration  -> Federation Settings Note the OIF Issuer/Provider ID value in the Provider Id field The OIF IdP SSO and Logout URLs are (note: be sure to have the public endpoints, which are the URLs that the end-user will use): Browser SSO URL: http(s)://oam-public-host:oam-public-port/oamfed/idp/samlv20 ECP SSO URL: http(s)://oam-public-host:oam-public-port/oamfed/idp/soap Logout URL: http(s)://oam-public-host:oam-public-port/oamfed/idp/samlv20 If you have any doubts, you can retrieve those URLs from the IdP metadata: Open a browser Go to http(s)://oam-public-host:oam-public-port/oamfed/idp/metadata The Browser SSO URL will be the Location attribute of the XML Element EntityDescriptor -> IDPSSODescriptor -> SingleSignOnService for which the Binding attribute is set to urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect:<md:EntityDescriptor ...>  ...  <md:IDPSSODescriptor ...>    ...    <md:SingleSignOnService  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://acme.com/oamfed/idp/samlv20"/>    ...  </md:IDPSSODescriptor>  ...</md:EntityDescriptor> The ECP SSO URL will be the Location attribute of the XML Element EntityDescriptor -> IDPSSODescriptor -> SingleSignOnService for which the Binding attribute is set to urn:oasis:names:tc:SAML:2.0:bindings:SOAP:<md:EntityDescriptor ...>  ...  <md:IDPSSODescriptor ...>    ...    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://acme.com/oamfed/idp/soap"/>    ...  </md:IDPSSODescriptor>  ...</md:EntityDescriptor> The Logout URL will be the Location attribute of the XML Element EntityDescriptor -> IDPSSODescriptor -> SingleLogoutService for which the Binding attribute is set to urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect:<md:EntityDescriptor ...>  ...  <md:IDPSSODescriptor ...>    ...    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://acme.com/oamfed/idp/samlv20" ResponseLocation="https://acme.com/oamfed/idp/samlv20"/>    ...  </md:IDPSSODescriptor>  ...</md:EntityDescriptor> SHA-256 vs SHA-1 After having setting up Federation between OIF and Office 365, you will need to configure OIF to use SHA-1 for signatures for the Office 365 SP partner. OIF’s Signing Certificate in Signed Messages After having setting up Federation between OIF and Office 365, you will need to configure OIF so that the Federation server will include its X.509 signing certificate in all outgoing signed SAML messages for the Office 365 SP partner. User Account The user accounts in Office 365 and in the OAM/OIF directory must be synchronized to support the various Federation flows (Browser SSO and ActiveSync): For a given user, both Office 365 and the directory used by OAM/OIF must have an account for that user The user global unique ID (or ImmutableId) and the email address (or UserPrincipalName) used in the Office 365 account must be set in the user account at OAM/OIF For the ActiveSync mail integration, the userID (or ImmutableId) used by Office 365 must be the username used for HTTP Basic Authentication at OAM/OIF: The identifier in the email address (or UserPrincipalName) is the part of the email address before the ‘@’ character. For example if the UserPrincipalName is alice.appleton@acme.com, then the identifier would be alice.appleton That identifier will be the HTTP Basic Authentication username. For example alice.appleton The User ID Attribute used in the OAM Identity Store configuration for the OAM HTTP Basic Authentication Scheme must match the incoming HTTP HTTP Basic Authentication username. For example the User ID Attribute used in the OAM Identity Store for user alice must be alice.appleton. ImmutableId The ImmutableId is an attribute used by Office 365 to uniquely reference a user. Even if the user record is to be deleted later on, no other user created subsequently should be able to have the same ImmutableId value. An ImmutableId is typically A random unique identifier (like 2848cfc7f6914af2a550c024bcbf0c6e) Or a username that will be deemed unique: no other user will have the same username even if the original user has been deleted from the system. UserPrincipalName The UserPrincipalName (or UPN) is an identifier that has the format of an email address. The domain name of the email address needs to map to the name used in the Office 365 domain. For example, if Office 365 was configured for the acme.com domain for Federation SSO, then all users with an email address similar to identifier@acme.com will be able to do Federation SSO with the IdP configured for that Office 365 domain. ActiveSync Requirements In an ActiveSync mail flow: The Office 365 mail server will make a direct connection over SSL to the IdP and will use the SAML 2.0 ECP protocol to send a SAML AuthnRequest and the user’s credentials via HTTP Basic Authentication The OIF/IdP will validate those credentials and return a SAML Assertion via the ECP protocol Office 365 will grant access to the mail application In such a flow, the user will: Provide its email address to Office 365 (alice.appleton@acme.com for example) Office 365 will use the identifier before the ‘@’ character as the HTTP Basic Authentication username (alice.appleton for example) IdP will need to be able to validate the credentials with the username being the identifier in the email address (alice.appleton for example) Username Requirements Based on the above, the requirements for the user authentication at the IdP are: Browser Authentication Username HTTP Basic Auth Username at IdP Browser based Federation SSO Anything N/A Browser based Federation SSO+ActiveSync ECP Anything Identifier in the email address In the next article, I will configure Office 365 and OIF/IdP and perform some tests.Cheers,Damien Carru

In the next two articles, I will describe how to integrate OIF (11.1.2.2.0 or later) as an IdP with Office 365 for Federation SSO using the SAML 2.0 protocol. The integration will cover: Browser...

JIT Custom User Provisioning in OIF / SP cont’d

This article is a continuation of my previous entry about User Provisioning in OIF/SP, where I described how to use the built-in module in OIF/SP to create user records during a Federation SSO operation, if the user did not have a local account. In this article, I will show how to build a custom User Provisioning module in OIF/SP. This will be based on the OAM/OIF 11.1.2.2.0 Developer’s Guide, chapter 16, which describes how to develop such a module. I will focus here on how to: Implement the plugin Compile it Package it Upload the plugin to OAM Configure OIF to use the newly uploaded plugin For this example, I will use the sample code listed in the OAM/OIF 11.1.2.2.0 Developer’s Guide. Enjoy the reading! Custom User Provisioning Module The User Provisioning framework allows the implementation of a custom plugin that implements the interfaces defined by the framework. A custom User Provisioning plugin is made of the following: One or more Java class implementing the custom User Provisioning plugin. One of the class will extend the oracle.security.fed.plugins.fed.provisioning.OIFUserProvisioningPlugin class A MANIFEST.MF file describing the Java classes An XML file describing the plugin Those three elements will be bundled in a JAR file that is then uploaded to the OAM server via the OAM Administration Console. Once uploaded and activated, it can be used at runtime by OIF/SP. Java Class The class implementing the custom User Provisioning module must adhere to the following: Extend the oracle.security.fed.plugins.fed.provisioning.OIFUserProvisioningPlugin class Implement the following methods: public ExecutionStatus process(UserContext context) throws UserProvisioningException This method is invoked when a user record needs to be created Must return a status (failure or success) In our example, this method will Check that the user data contained in the UserContext has the required information Open a connection to the LDAP server Create a user record public String getPluginName() Returns the name of the custom User Provisioning module In our example it will return "CustomProvisioningPlugin" public String getDescription() Returns a description of the custom User Provisioning module In our example it will return "Custom Provisioning Plugin" public Map<String, MonitoringData> getMonitoringData() Not used in a User Provisioning flow In our example it will return null public boolean getMonitoringStatus() Not used in a User Provisioning flow In our example it will return false public int getRevision() Must be the same value than the version specified in the manifest file In our example it will return 10 public void setMonitoringStatus(boolean status) Not used in a User Provisioning flow In our example this method will be empty The class will have to implement the org.osgi.framework.BundleActivator interface and the following methods: public void start(BundleContext arg0) throws Exception In our example this method will be empty public void stop(BundleContext arg0) throws Exception In our example this method will be empty Optionally, if the plugin needs to read configuration data from the Plugin settings, the initialize() method can be implemented: public ExecutionStatus initialize(PluginConfig config) In our example, this method will read the user base DN from a setting entry in the plugin config: USER_BASE_DN The following code is an example of the custom plugin called CustomerUserProvisioning. package userprov;import java.util.Collection;import java.util.Hashtable;import java.util.Map;import javax.naming.Context;import javax.naming.directory.BasicAttribute;import javax.naming.directory.BasicAttributes;import javax.naming.directory.InitialDirContext;import oracle.security.am.plugin.ExecutionStatus;import oracle.security.am.plugin.MonitoringData;import oracle.security.am.plugin.PluginConfig;import oracle.security.fed.plugins.fed.provisioning.OIFUserProvisioningPlugin;import oracle.security.fed.plugins.fed.provisioning.UserContext;import oracle.security.fed.plugins.fed.provisioning.UserProvisioningException;public class CustomUserProvisioning extends OIFUserProvisioningPlugin implements org.osgi.framework.BundleActivator{    private String userBaseDN = null;     public ExecutionStatus initialize(PluginConfig config)    {        ExecutionStatus status = super.initialize(config);        if (status.getStatus() == ExecutionStatus.SUCCESS.getStatus())            userBaseDN = (String)config.getParameter("USER_BASE_DN");        return status;    }    public ExecutionStatus process(UserContext context) throws UserProvisioningException    {        try        {            // get user data            // after OIF/SP processing of the attributes sent by the IdP, we expect            // givenname, sn, mail as well as fed.nameidvalue which would contain            //  the userid            Map assertionAttributes = context.getAttributes();            Collection collection = (Collection)assertionAttributes.get("givenname");            String firstname = (String)(collection.size() > 0 ? collection.iterator().next() : null);            collection = (Collection)assertionAttributes.get("sn");            String lastname = (String)(collection.size() > 0 ? collection.iterator().next() : null);            collection = (Collection)assertionAttributes.get("mail");            String email = (String)(collection.size() > 0 ? collection.iterator().next() : null);            collection = (Collection)assertionAttributes.get("fed.nameidvalue");            String userid = (String)(collection.size() > 0 ? collection.iterator().next() : null);            // check that the required attributes are present. If not, return an error            if (firstname == null || firstname.length() == 0 ||                lastname == null || lastname.length() == 0 ||                email == null || email.length() == 0 ||                userid == null || userid.length() == 0)            {                // failure                return ExecutionStatus.FAILURE;            }             String ldap = "ldap://adc00pcc.us.oracle.com:11389";            String username = "cn=orcladmin";            String password = "welcome1";             // connects to the LDAP directory            Hashtable env = new Hashtable();            env.put(Context.INITIAL_CONTEXT_FACTORY,                "com.sun.jndi.ldap.LdapCtxFactory");            env.put(Context.PROVIDER_URL, ldap);            if (ldap.toLowerCase().startsWith("ldaps"))                env.put(Context.SECURITY_PROTOCOL, "ssl");            env.put(Context.SECURITY_AUTHENTICATION, "simple");            env.put(Context.REFERRAL, "follow");            env.put(Context.SECURITY_PRINCIPAL, username);            env.put(Context.SECURITY_CREDENTIALS, password);                  InitialDirContext ldapContext = new InitialDirContext(env);             // create the user entry            BasicAttributes attributes = new BasicAttributes();             // object classes            BasicAttribute objClassAttr = new BasicAttribute("objectClass");            objClassAttr.add("person");            objClassAttr.add("organizationalPerson");            objClassAttr.add("inetOrgPerson");            objClassAttr.add("top");            attributes.put(objClassAttr);             // uid attr            attributes.put(new BasicAttribute("uid", userid));            // first name            attributes.put(new BasicAttribute("givenname", firstname));            // last name            attributes.put(new BasicAttribute("sn", lastname));            // email            attributes.put(new BasicAttribute("mail", email));            // DN: cn will be set to userID            String dn = "cn=" + userid + (userBaseDN != null &&                 userBaseDN.length() > 0 ? "," + userBaseDN : "");             // create the user record            ldapContext.createSubcontext(dn, attributes);             // return success            return ExecutionStatus.SUCCESS;        }        catch (Exception ex)        {            ex.printStackTrace();            return ExecutionStatus.FAILURE;        }    }    public String getPluginName()    {        return "CustomProvisioningPlugin";    }    public String getDescription()    {        return "Custom Provisioning Plugin";    }    public Map<String, MonitoringData> getMonitoringData()    {        return null;    }    public boolean getMonitoringStatus()    {        return false;    }    public int getRevision()    {        return 10;    }    public void setMonitoringStatus(boolean status)    {    }    public void start(BundleContext arg0) throws Exception    {    }    public void stop(BundleContext arg0) throws Exception    {    }} Plugin Registration File The custom User Provisioning plugin must be defined in a plugin XML file such as: <Plugin type="User Provisioning"><author>uid=admin</author><email>admin@example</email><creationDate>08:00:00,2014-01-15</creationDate><description>Custom Provisioning Plugin</description><configuration> <AttributeValuePair>  <Attribute type="string" length="100">USER_BASE_DN</Attribute>  <mandatory>false</mandatory>  <instanceOverride>false</instanceOverride>  <globalUIOverride>false</globalUIOverride>  <value> </value> </AttributeValuePair></configuration></Plugin> Important Note: the XML file must have the same name as the class implementing the plugin, in this case CustomUserProvisioning.xml See the OAM/OIF 11.1.2.2.0 Developer’s Guide for more information Manifest File Before packaging the custom User Provisioning plugin in a JAR file, a MANIFEST.MF must be defined such as:    Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: CustomUserProvisioningBundle-SymbolicName: CustomUserProvisioningBundle-Version: 10Bundle-Activator: userprov.CustomUserProvisioningImport-Package: org.osgi.framework;version="1.3.0",oracle.security.fed .plugins.fed.provisioning,javax.naming,javax.naming.directory,oracle. security.am.pluginBundle-RequiredExecutionEnvironment: JavaSE-1.6 See the OAM/OIF 11.1.2.2.0 Developer’s Guide for more information Note: the manifest file must include the Import-Package property which lists all the packages that are used in the plugin Building the Plugin Compiling The following JAR files from the OAM deployment need to be used for compilation: felix.jar oam-plugin.jar fed.jar These files are found in the following locations: felix.jar: $IAM_HOME/oam/server/lib/plugin/felix.jar oam-plugin.jar: $IAM_HOME/oam/server/lib/plugin/oam-plugin.jar fed.jar: in the $DOMAIN_HOME/servers/MANAGED_INSTANCE_NAME/tmp/_WL_user/oam_server/RANDOM_STRING/APP-INF/lib, with RANDOM_STRING being a directory name with random characters, for example 88g74i in my test installation In my example, I put the CustomerUserProvisioning.java file in a src/userprov folder: bash-4.1$ ls -l src/userprov/total 8-rw-r--r-- 1 root root 4717 Mar 1 11:42 CustomUserProvisioning.java To compile, execute the following command: $JDK_HOME/bin/javac -cp $IAM_HOME/oam/server/lib/plugin/felix.jar:$IAM_HOME/oam/server/lib/plugin/oam-plugin.jar:/tmp/oam-server/APP-INF/lib/fed.jar src/userprov/*.java Packaging the Custom Plugin I created the MANIFEST.MF in the current directory based on the content listed in the previous section, and the CustomUserProvisioning.xmlin the src directory, which contains the plugin definition listed in the previous section. find../MANIFEST.MF./src./src/userprov./src/userprov/CustomUserProvisioning.class./src/userprov/CustomUserProvisioning.java./src/CustomUserProvisioning.xml To create the CustomUserProvisioning.jar JAR file that will contain the plugin and the required files, execute the following command: jar cfvm CustomUserProvisioning.jar MANIFEST.MF -C src/ .added manifestadding: userprov/(in = 0) (out= 0)(stored 0%)adding: userprov/CustomUserProvisioning.class(in = 3991) (out= 1954)(deflated 51%)adding: userprov/CustomUserProvisioning.java(in = 4717) (out= 1401)(deflated 70%)adding: CustomUserProvisioning.xml(in = 486) (out= 266)(deflated 45%) This will create the CustomUserProvisioning.jar. To view the contents of the file: unzip -l CustomUserProvisioning.jarArchive:  CustomUserProvisioning.jar  Length      Date    Time    Name---------  ---------- -----   ----        0  03-01-2014 14:32   META-INF/      404  03-01-2014 14:32   META-INF/MANIFEST.MF        0  03-01-2014 12:10   userprov/     3991  03-01-2014 12:10   userprov/CustomUserProvisioning.class     4717  03-01-2014 11:42   userprov/CustomUserProvisioning.java      486  03-01-2014 14:04   CustomUserProvisioning.xml---------                     -------     9598                     6 files Important Note: the JAR file must have the same name as the class implementing the plugin, in this case CustomUserProvisioning.jar Deploying the Custom Provisioning Module Perform the following steps to deploy the custom User Provisioning plugin in OAM: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Plugins Click Import Plug-In Select the plugin JAR file (CustomUserProvisioning.jar in this example) The plugin will be in an uploaded state: You will need to distribute the plugin to the runtime OAM servers and activate it: Select the plugin Click Distribute Selected The Activation Status tab of the plugin will show the state of the plugin You will need to activate the plugin: Select the plugin Click Activate Selected The Activation Status tab of the plugin will show the state of the plugin Finally, the plugin will need to be configured for user base DN. Perform the following steps: Select the plugin Click on the Configuration Parameters tab of the plugin Enter the User Base DN (for example for the directory I am using: ou=users,dc=us,dc=oracle,dc=com) Save Using the Custom User Provisioning Module Enabling the User Provisioning in OIF To enable/disable User Provisioning in OIF/SP, execute the following steps: 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() Update the userprovisioningenabled property to: Enable User Provisioning in OIF/SP:putBooleanProperty("/fedserverconfig/userprovisioningenabled", "true") Disable User Provisioning in OIF/SP:putBooleanProperty("/fedserverconfig/userprovisioningenabled", "false") Exit the WLST environment:exit() Configuring OIF to use the Custom Plugin To configure OIF/SP to use the custom plugin, execute the following steps: 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() Update the userprovisioningplugin property to: Configure OIF to use the custom plugin, set the property to the plugin name (in our example CustomUserProvisioning):putStringProperty("/fedserverconfig/userprovisioningplugin", "CustomUserProvisioning") Configure OIF to use the built-in User Provisioning module:putStringProperty("/fedserverconfig/userprovisioningplugin", "FedUserProvisioningPlugin") Exit the WLST environment:exit() Testing Setup I will use the same SAML 2.0 Federation setup that was configured in the previous articles, where: OIF acts as a Service Provider The IdP (AcmeIdP) will send a SAML Assertion with NameID set to userID Attributes sent: email set to user’s email address fname set to user’s first name surname set to user’s last name title set to user’s last job title OIF/SP configured with an IdP Attribute Profile to Map fname to givenname Map surname to sn Map email to mail User alice will be used at the IdP, while no user account for alice exists at OIF/SP: userID: alice email: alice@oracle.com first name: Alice last name: Appleton title: manager During a SAML 2.0 Federation SSO with the remote IdP partner, the XML SAML Response with the Assertion sent back by the IdP would be: <samlp:Response ..>    <saml:Issuer ...>http://acme.com/idp</saml:Issuer>    <samlp:Status>        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>    </samlp:Status>    <saml:Assertion ...>        <saml:Issuer ...>http://acme.com/idp</saml:Issuer>        <dsig:Signature ...>        ...        </dsig:Signature>        <saml:Subject>            <saml:NameID ...>alice</saml:NameID>            ...        </saml:Subject>        <saml:Conditions ...>         ...        </saml:Conditions>        <saml:AuthnStatement ...>        ...        </saml:AuthnStatement>        <saml:AttributeStatement ...>            <saml:Attribute Name="email" ...>                <saml:AttributeValue ...>alice@oracle.com</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="title" ...>                <saml:AttributeValue ...>manager</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="surname" ...>                <saml:AttributeValue ...>Appleton</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="fname" ...>                <saml:AttributeValue ...>Alice</saml:AttributeValue>            </saml:Attribute>        </saml:AttributeStatement>    </saml:Assertion></samlp:Response> The result of the processing of the SAML 2.0 Assertion by OIF/SP will show the transformed attributes as well as the NameID Test After Federation SSO, the user record for alice was created: dn: uid=alice,ou=users,dc=us,dc=oracle,dc=commail: alice@oracle.comgivenName: AliceobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topuid: alicecn: alicesn: alicesn: Appleton In my next article, I will describe how to integrate OIF (11.1.2.2.0 or later) as an IdP with Office365 for Federation SSO using the SAML 2.0 protocol.Cheers,Damien Carru

This article is a continuation of my previous entry about User Provisioning in OIF/SP, where I described how to use the built-in module in OIF/SP to create user records during a Federation SSO...

JIT User Provisioning in OIF / SP

In this article, I will discuss on how to add user provisioning to OIF/SP which allows the server to create a user record on the fly during Federation SSO, if the user does not have an account yet. During a Federation SSO operation, OIF/SP will validate the incoming SSO response (SAML or OpenID) and will attempt to map it to a local LDAP user record based on information contained in the SSO response (typically user attributes): If the mapping returns a single user record, the operation is a success and an OAM session is created for that user record If the mapping returns several LDAP records, then the operation is a non-recoverable failure: Either the mapping configuration is incorrect Or there are invalid LDAP user records in the directory If the mapping does not return any records, this means that Either the mapping configuration is incorrect Or the configuration is correct, but the user does not have a record in the local directory: in this case, OIF/SP can be set up to automatically create an LDAP user record based on the data contained in the SSO response, and ensure that subsequent Federation SSO mapping operations for that user will map to the same new LDAP user record OIF/SP will validate the SSO response, process the attributes using rules defined in the IdP Attribute Profile for the IdP partner, and if needed will invoke the User Provisioning module configured in OIF/SP: Either the included User Provisioning module Or a custom implementation of a User Provisioning module After the invocation of the User Provisioning module (default or custom), the server will create a session for the user. Subsequent Federation SSO operations for the same user will result in OIF/SP mapping the SSO response to that newly created LDAP record. Enjoy the reading! Built-in User Provisioning Module The built-in User Provisioning module allows a user record to be created in the LDAP directory when mapping fails by: Using the Identity Store specified in the IdP partner entry, or the default OAM Identity Store if none is specified Using the User Base DN specified in the IdP partner entry, or the User Base DN for the Identity Store that is used, if none is specified Creating a user record with a userID based on an attribute contained in the SAML/OpenID SSO Response: Either the User Provisioning module configuration indicates which attribute to use as the userID (for example foo) The module will attempt to locate that attribute in the list of attributes from the SSO response after those attributes were processed by the IdP Attribute Profile (for example the module will look for the foo attribute in the list of processed attribute from the SSO response) If the attribute is not in the list of attributes from the SSO response, the module will evaluate the mapping rule specified in the IdP Partner entry: if the mapping rule uses the userID attribute, then it will use the mapped data as the userID (for example, if the SAML Assertion was mapped via NameID to an LDAP user record using the foo LDAP attribute, then the module will use the NameID value as the userID) Or the User Provisioning module configuration does not indicate which attribute to use as the userID or if the userID attribute could not be determined following the above flow, the module will look at the Identity Store configuration to determine the userID attribute (for example uid) and it will follow the process listed above: The module will attempt to locate that attribute in the list of attributes from the SSO response after those attributes were processed by the IdP Attribute Profile (for example the module will look for the uid attribute in the list of processed attribute from the SSO response) If the attribute is not in the list of attributes from the SSO response, the module will evaluate the mapping rule specified in the IdP Partner entry: if the mapping rule uses the userID attribute, then it will use the mapped data as the userID (for example, if the SAML Assertion was mapped via NameID to an LDAP user record using the uid LDAP attribute, then the module will use the NameID value as the userID) If the userID attribute could still not be determined (because uid is not in the list of attributes sent by the IdP for example), the module will attempt to use the NameID value as the userID If present it will use it Otherwise an error will be thrown since the User Provisioning module cannot select a userID value. Important note: the above algorithm is somewhat complex, but it allows an administrator To test user provisioning in a POC without having to perform multiple configuration steps As well as to configure the user provisioning moduble to the administrator’s needs. Once the user record has been created, the User Provisioning module will set attributes on the user record based on: The list of attributes that should be set: this is indicated by the module’s configuration set by the administrator, which dictates the list of attributes from the SSO response to set The attributes listed in the mapping rule: the attributes listed in the mapping rule of the IdP Partner entry will be automatically set in the LDAP user record, to ensure that the mapping will function the next time the user with an identical SSO response performs Federation SSO with OIF/SP. Enabling User Provisioning in OIF/SP To enable/disable User Provisioning in OIF/SP, execute the following steps: 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() Update the userprovisioningenabled property to: Enable User Provisioning in OIF/SP:putBooleanProperty("/fedserverconfig/userprovisioningenabled", "true") Disable User Provisioning in OIF/SP:putBooleanProperty("/fedserverconfig/userprovisioningenabled", "false") Exit the WLST environment:exit() Testing Setup I will use the same SAML 2.0 Federation setup that was configured in the previous articles, where: OIF acts as a Service Provider The IdP (AcmeIdP) will send a SAML Assertion with NameID set to userID Attributes sent: email set to user’s email address fname set to user’s first name surname set to user’s last name title set to user’s last job title OIF/SP configured with an IdP Attribute Profile to Map fname to givenname Map surname to sn Map email to mail User alice will be used at the IdP, while no user account for alice exists at OIF/SP: userID: alice email: alice@oracle.com first name: Alice last name: Appleton title: manager During a SAML 2.0 Federation SSO with the remote IdP partner, the XML SAML Response with the Assertion sent back by the IdP would be: <samlp:Response ..>    <saml:Issuer ...>http://acme.com/idp</saml:Issuer>    <samlp:Status>        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>    </samlp:Status>    <saml:Assertion ...>        <saml:Issuer ...>http://acme.com</saml:Issuer>        <dsig:Signature ...>        ...        </dsig:Signature>        <saml:Subject> <saml:NameID ...>alice</saml:NameID>            ...        </saml:Subject>        <saml:Conditions ...>         ...        </saml:Conditions>        <saml:AuthnStatement ...>        ...        </saml:AuthnStatement>        <saml:AttributeStatement ...>            <saml:Attribute Name="email" ...>                <saml:AttributeValue ...>alice@oracle.com</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="title" ...>                <saml:AttributeValue ...>manager</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="surname" ...>                <saml:AttributeValue ...>Appleton</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="fname" ...>                <saml:AttributeValue ...>Alice</saml:AttributeValue>            </saml:Attribute>        </saml:AttributeStatement>    </saml:Assertion></samlp:Response> The result of the processing of the SAML 2.0 Assertion by OIF/SP will show the transformed attributes as well as the NameID Test Cases I will showcase different configurations for the User Provisioning module, with the user alice not existing in OIF/SP before each test: Use Case #1: No User Provisioning module configuration Mapping rule is done via NameID to LDAP uid attribute Use Case #2: No User Provisioning module configuration Mapping rule is done via SAML Attribute mail to LDAP mail attribute Use Case #3: Mapping rule is done via NameID to LDAP uid attribute User Provisioning module configured to set givenname, sn and mail attributes Use Case #4: Mapping rule is done via SAML Attribute mail to LDAP mail attribute User Provisioning module configured to use givenname as the userID Use Case #5: Mapping rule is done via SAML Attribute mail to LDAP mail attribute User Provisioning module configured to Use NameID as the userID Set givenname and sn attributes After each Federation SSO operation, I will print out the LDAP user record of the user created. I will subsequently delete that record before the next test. Important note: the IdP Attribute Profile must map the incoming SAML Attribute names to the attribute names that will be used in the LDAP directory. That’s why in our test IdP Attribute Profile, fname is mapped to givenname. The built-in User Provisioning plugin will take the attribute names from the list of processed attributes and add them as is to the LDAP user record (if configured to do so): there is no additional attribute name mapping. Use Case #1 In this use case, the setup is such that: No User Provisioning module configuration Mapping rule is done via NameID to LDAP uid attribute After Federation SSO, the user record for alice was created: dn: uid=alice,ou=users,dc=us,dc=oracle,dc=comobjectClass: personobjectClass: organizationalPersonobjectClass: inetOrgPersonobjectClass: topuid: alicecn: alicesn: alice The LDAP user record has the following characteristics: UserID: There was no User Provisioning module configuration The User Provisioning module checked if the User Identity Store UserID (uid in the test) was an attribute sent by the IdP: this was not the case The User Provisioning module used the NameID as the userID (which is the test will be stored in the LDAP uid attribute): uid was set to alice Extra attributes: The User Provisioning module set the attribute(s) that was used in the mapping rule: NameID was mapped to uid. This attribute was already set (as the userID). cn and sn are mandatory attributes as per the LDAP schema used in this test, and if not explicitly specified, userID is used to populate those attributes Use Case #2 In this use case, the setup is such that: No User Provisioning module configuration Mapping rule is done via SAML Attribute mail to LDAP mail attribute After Federation SSO, the user record for alice was created: dn: uid=alice,ou=users,dc=us,dc=oracle,dc=commail: alice@oracle.comobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topuid: alicecn: alicesn: alice The LDAP user record has the following characteristics: UserID: There was no User Provisioning module configuration The User Provisioning module checked if the User Identity Store UserID (uid in the test) was an attribute sent by the IdP: this was not the case The User Provisioning module used the NameID as the userID (which is the test will be stored in the LDAP uid attribute): uid was set to alice Extra attributes: The User Provisioning module set the attribute(s) that was used in the mapping rule: the email attribute in the SAML assertion was mapped to mail. The mail attribute was set to alice@oracle.com. cn and sn are mandatory attributes as per the LDAP schema used in this test, and if not explicitly specified, userID is used to populate those attributes Use Case #3 In this use case, the setup is such that: Mapping rule is done via NameID to LDAP uid attribute User Provisioning module configured to set givenname, sn and mail attributes. To do so, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Plugins Select the FedUserProvisioningPlugin In the KEY_USER_RECORD_ATTRIBUTE_LIST field, enter givenname, sn and mail as a comma separated list without spaces: givenname,sn,mail Save After Federation SSO, the user record for alice was created: dn: uid=alice,ou=users,dc=us,dc=oracle,dc=commail: alice@oracle.comgivenName: AliceobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topuid: alicecn: alicesn: alicesn: Appleton The LDAP user record has the following characteristics: UserID: There was no User Provisioning module configuration for userID The User Provisioning module checked if the User Identity Store UserID (uid in the test) was an attribute sent by the IdP: this was not the case The User Provisioning module used the NameID as the userID (which is the test will be stored in the LDAP uid attribute): uid was set to alice Extra attributes: The User Provisioning module set the attribute(s) that was used in the mapping rule: NameID was mapped to uid. This attribute was already set (as the userID). The User Provisioning module retrieved the givenname, sn and mail attributes from the list of processed attributes and set those on the LDAP user record. cn is a mandatory attribute as per the LDAP schema used in this test, and if not explicitly specified, userID is used to populate that attribute Use Case #4 In this use case, the setup is such that: Mapping rule is done via SAML Attribute mail to LDAP mail attribute User Provisioning module configured to use givenname as the userID To do so, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Plugins Select the FedUserProvisioningPlugin Set the KEY_USER_RECORD_ATTRIBUTE_LIST field to blank value Set the KEY_USERID_ATTRIBUTE_NAME field to givenname Save After Federation SSO, the user record for alice was created: dn: uid=Alice,ou=users,dc=us,dc=oracle,dc=commail: alice@oracle.comobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topuid: Alicecn: Alicesn: Alice The LDAP user record has the following characteristics: UserID: The User Provisioning module was configured to use givenname as the userID Extra attributes: The User Provisioning module set the attribute(s) that was used in the mapping rule: the email attribute in the SAML assertion was mapped to mail. The mail attribute was set to alice@oracle.com. cn and sn are mandatory attributes as per the LDAP schema used in this test, and if not explicitly specified, userID is used to populate those attributes Use Case #5 In this use case, the setup is such that: Mapping rule is done via SAML Attribute mail to LDAP mail attribute User Provisioning module configured to Use NameID as the userID Set givenname and sn attributes To do so, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Plugins Select the FedUserProvisioningPlugin Set the KEY_USER_RECORD_ATTRIBUTE_LIST field to (comma separated list without spaces): givenname,sn Set the KEY_USERID_ATTRIBUTE_NAME field to fed.nameidvalue, which is the name of the attribute for the NameID value Save After Federation SSO, the user record for alice was created: dn: uid=alice,ou=users,dc=us,dc=oracle,dc=commail: alice@oracle.comgivenName: AliceobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topuid: alicecn: alicesn: alicesn: Appleton The LDAP user record has the following characteristics: UserID: The User Provisioning module was configured to use the NameID value (fed.nameidvalue) as the userID Extra attributes: The User Provisioning module set the attribute(s) that was used in the mapping rule: the email attribute in the SAML assertion was mapped to mail. The mail attribute was set to alice@oracle.com. The User Provisioning module retrieved the givenname and sn attributes from the list of processed attributes and set those on the LDAP user record. cn is a mandatory attribute as per the LDAP schema used in this test, and if not explicitly specified, userID is used to populate that attribute In my next article, I will show how a custom User Provisioning module can be implemented and used by OIF/SP to create user records on the fly.Cheers,Damien Carru

In this article, I will discuss on how to add user provisioning to OIF/SP which allows the server to create a user record on the fly during Federation SSO, if the user does not have an account yet. Duri...

Using Fed Attributes: OAM Authorization and HTTP Headers

In this article, I will discuss how attributes received in SAML/OpenID SSO messages can be used in OAM Authorization Policies and how they can be provided to protected web applications. At runtime, when OIF/SP successfully processes a SAML / OpenID SSO Response message, the server will save some of the information from the response in the OAM session, as attributes that can be used in OAM authorization policies In conditions for authorization rulesIn responses to provide the SAML/OpenID attributes to protected web applications The SAML / OpenID SSO Response information is saved in the OAM session as attributes referenced by the following identifiers: The IdP partner name, referenced by $session.attr.fed.partnerThe NameID value from the SSO response, referenced by $session.attr.fed.nameidvalueThe NameID format from the SSO response, for SAML protocols, referenced by $session.attr.fed.nameidformatThe attributes contained either in the SAML Assertion’s AttributeStatement or in the OpenID SSO Response, referenced by $session.attr.fed.attr.ATTR_NAME, with ATTR_NAME being Either the local session attribute name, if an IdP Attribute Profile mapping was applied (see previous article)Or the attribute name from the SSO response, if no IdP Attribute Profile mapping was applied for this attribute Enjoy the reading! Overview A typical OAM environment is made of the following: LDAP directoryOAM admin server, with the OAM admin consoleOAM runtime serverWeb applicationsWebGate agents protecting web application on HTTP servers (OHS, IIS…) When an authenticated user requests access to a protected resource: WebGate intercepts the call and ensures thatThe user is authenticatedThe user is authorized to access the resource by evaluating authorization policies for this resourceWebGate will inject data, as cookies or HTTP headers, into the HTTP request that will be forwarded to the protected resource The OAM Authorization Policies used to evaluate whether a user can access a resource or not can be based on various conditions: Identity: condition based on the user’s identity or groups to which the user belongsIP Address: condition based on the user’s IP address Temporal: condition based on timeAttributes: condition based on attributes (LDAP, HTTP request or session attributes). An administrator could use the Federation data received in the SAML/OpenID SSO message in an authorization rule, by using an attribute condition that would evaluate the Federation attributes. The OAM Authorization Responses which are used to inject data into the HTTP request to make it available to protected web applications are based on User LDAP attributesHTTP request dataStatic stringsOAM session attributes Similarly to the OAM Authorization Policies, an administrator can inject federation data into the HTTP request via the use of OAM session attributes referencing the federation entries ($session.attr.fed.partner, $session.attr.fed.attr.ATTR_NAME…) Federation SSO Setup I will use the same SAML 2.0 Federation setup that was configured for the previous article, where: OIF acts as a Service ProviderThe IdP (AcmeIdP) will send a SAML Assertion withNameID set to userIDAttributes sent:email set to user’s email addressfname set to user’s first namesurname set to user’s last nametitle set to user’s last job titleOIF/SP configured with an IdP Attribute Profile toMap fname to firstnameMap surname to lastnameLeave email as is Two users will be used: Alice:userID: aliceemail: alice@oracle.comfirst name: Alicelast name: Appletontitle: managerBob:userID: bobemail: bob@oracle.comfirst name: Bobbylast name: Smithtitle: engineer The XML SAML Response with the Assertion sent back by the IdP is: <samlp:Response ..>    <saml:Issuer ...>http://acme.com/idp</saml:Issuer>    <samlp:Status>        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>    </samlp:Status>    <saml:Assertion ...>        <saml:Issuer ...>http://acme.com/idp</saml:Issuer>        <dsig:Signature ...>        ...        </dsig:Signature>        <saml:Subject>            <saml:NameID ...>alice</saml:NameID>            ...        </saml:Subject>        <saml:Conditions ...>         ...        </saml:Conditions>        <saml:AuthnStatement ...>        ...        </saml:AuthnStatement>        <saml:AttributeStatement ...>            <saml:Attribute Name="email" ...>                <saml:AttributeValue ...>alice@oracle.com</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="title" ...>                <saml:AttributeValue ...>manager</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="surname" ...>                <saml:AttributeValue ...>Appleton</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="fname" ...>                <saml:AttributeValue ...>Alice</saml:AttributeValue>            </saml:Attribute>        </saml:AttributeStatement>    </saml:Assertion></samlp:Response> The Test SP page shows different results, since OIF/SP processed the attributes according to the rules where: email was not changedtitle was not changedfname was mapped to firstnamesurname was mapped to lastname Protected Web Application In this example, I am using the following components: OHS is installedA WebGate agent has been configured for this OHS instanceAn OAM Application Domain has been created for this WebGate, which protects all the resources on the OHS serverAuthentication Policy: Name: “Protected Resource Policy”Authentication Scheme: FederationSchemeAuthorization Policy:Name: “Protected Resource Policy”Resources/** and /…/* Linked to “Protected Resource Policy” Authentication Policy and “Protected Resource Policy” Authorization PolicyThe /cgi-bin/printenv resource on OHS prints out data when processing the the HTTP Request sent by the browserHTTP HeadersRequest data (path, query string...)Server data (IP address, port…) An example of a browser accessing the resource without being protected by OAM/WebGate would result in the following display (in the test, the web application will be protected as listed above): Authorization Conditions I will show as an example how to construct an Authorization Policy using a Federation attributes stored in the OAM session for a resource with the following constraints: Users will be authenticated via Federation SSO (so the resource is protected via a FederationScheme Authentication Policy)The IdPs provide the job title of the user, and it will be known locally as title (if the IdP sends the job title via a name different than title, then an IdP Attribute Profile will need to be used to map it to the local title name)Only users with the manager title should have access to the resource To create such an authorization policy, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsoleNavigate to Access Manager -> Application DomainsSearch and click on the Application Domain for the resourceClick on the Authorization PoliciesOpen the Authorization Policy protecting the resource (“Protected Resource Policy” in this example)Click on the Conditions tabClick Add to define a new condition:Name: TitleConditionType: AttributeClick Add Selected Execute the following steps: Select the newly created conditionIn the Condition Details window, click Add:Namespace: SessionAttribute Name: OtherEnter the attribute name: fed.titleOperator: EqualsAttribute Value: managerClick OK Execute the following steps: Click on the Rules tabRemove the TRUE condition if present in the Allow Rule -> Selected ConditionsAdd the TitleCondition to the Allow Rule -> Selected ConditionsApply To test, in a fresh browser access the protected resource: you will be redirected to the IdP. If you authenticate at the IdP with alice, the browser will show the following at the end of the flow, showing the Remote User HTTP header set to alice (since the IdP provided the title attribute set to manager and OAM only allows access to users with the OAM session attribute fed.title set to manager): If you authenticate at the IdP with bob, the browser will show the following at the end of the flow, showing an error (since the IdP provided the title attribute set to engineer and OAM only allows access to users with the OAM session attribute fed.title set to manager): Injecting Fed Attributes I will show as an example how to inject SAML / OpenID attributes collected from the SSO response as HTTP Headers for the protected Web with the following constraints: Users will be authenticated via Federation SSO (so the resource is protected via a FederationScheme Authentication Policy)The IdPs provide the job title of the user, and it will be known locally as title (if the IdP sends the job title via a name different than title, then an IdP Attribute Profile will need to be used to map it to the local title name)OAM/WebGate will be configured to inject:Email address as emailaddressFirst name as firstnameLast name as lastnameThe configuration will be done via the use of Authorization Response objects in an Authorization Policy definition To configure such an authorization policy, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsoleNavigate to Access Manager -> Application DomainsSearch and click on the Application Domain for the resourceClick on the Authorization PoliciesOpen the Authorization Policy protecting the resource (“Protected Resource Policy” in this example)Click on the Responses tabClick Add to create the entry for the email address:Type: HeaderName: emailaddressValue: $session.attr.fed.attr.emailAdd Execute the following steps: Click Add to create the entry for the first name:Type: HeaderName: firstnameValue: $session.attr.fed.attr.firstnameAddClick Add to create the entry for the last name:Type: HeaderName: lastnameValue: $session.attr.fed.attr.lastnameAddApply To test, in a fresh browser access the protected resource: you will be redirected to the IdP where authentication will occur. OAM/WebGate will then inject the Authorization Response items based on the OAM Session attributes (received from the IdP) and the protected web application will display those (my test page will display an HTTP header as HTTP_NAME, with NAME being the name of the HTTP Header). In my next article, I will discuss on how to add user provisioning to OIF/SP which allows the server to create a user record on the fly during Federation SSO, if the user does not have an account yet.Cheers,Damien Carru

In this article, I will discuss how attributes received in SAML/OpenID SSO messages can be used in OAM Authorization Policies and how they can be provided to protected web applications. At runtime,...

Processing Incoming Attributes with OIF / SP

When OIF acts as a Service Provider, it: Validates the incoming SSO response from the IdP Maps the SSO response to an LDAP user record Extracts the user identifier and optional attributes contained in the SSO response and stores them in the OAM session. Those attributes stored in the OAM session can later be used: In Authorization Policies, where the conditions/rules will evaluate the attributes in the OAM session As Policy Responses to provide those attributes to web applications protected by WebGate/OAM, as HTTP Headers or cookies In this article, I will discuss how OIF acting as a Service Provider can be configured to: Process attributes contained in an incoming SAML Assertion or OpenID SSO Response to map the names of incoming attributes to local names. Request attributes from the OP via the OpenID protocol (SAML does not provide a way for SPs at runtime to request attributes from the IdP during a Federation SSO operation) Enjoy the reading! Overview Attribute Name Mapping The main reason for processing incoming attributes is to map the names of the attributes from the SSO response to local names, recognized by other local components. This feature is useful in Federation deployments, because different remote partners sometimes use different names to reference the same attribute. For example, let’s assume the following use case: IdP1 sends the user’s first name as firstname in the SAML Assertion IdP2 sends the user’s first name as f_name in the SAML Assertion The local components (protected applications, OAM…) expect to reference the user’s first name as first_name at runtime By processing the incoming attributes, OIF/SP can map: firstname to first_name for IdP1 f_name to first_name for IdP2 This allows the consumer of the data sent in SAML/OpenID messages to reference the user’s first name only by the first_name identifier: An authorization policy condition will only reference the first name from the OAM session using first_name A policy response will reference the first name from the OAM session using first_name The policy objects are not aware of firstname or f_name used by the remote IdPs Requesting Attributes The OpenID 2.0 protocol defines a way for SP/RP partners to request attributes from the IdP/OP at runtime. OIF/SP provides a way to request attributes from the OpenID OP Attribute Profiles In a previous article, I explained what SP Attributes Profiles were in OIF/IdP and how to use them: They define which attributes should be sent to SP partners How the attributes should be named How to set the values of those attributes Whether those attributes should always be sent or only when requested In OIF/SP, there is a similar concept for requesting attributes and mapping attribute names. The IdP Attribute Profile is a collection of rules that indicates to OIF/SP: Which attributes should be requested at runtime (OpenID 2.0 only) How the names of attributes contained in SAML/OpenID messages should be mapped to locally Examples In the rest of the article, I will showcase how OIF/SP can be configured to: Map incoming attribute names to local names, via the OAM Administration Console, for a remote SAML 2.0 IdP Request attributes at runtime and map incoming attribute names to local names, via OIF WLST commands, for a remote OpenID 2.0 OP I will use the Test SP Application bundled with OIF/SP to see how the attributes of the SAML/OpenID SSO Response are processed. Mapping Incoming Attributes In this section, I will show how to configure OIF/SP to process incoming SAML 2.0 attributes via the admin console. The example will be based on a Federation with a remote SAML 2.0 IdP partner identified as AcmeIdP in OIF/SP: The IdP is sending Unspecified as the NameID format The NameID value will contain the user ID The Assertion will contain the following SAML Attributes The user’s first name, identified by fname The user’s last name, identified by surname The user’s email address, identified by email OIF/SP will first be configured to not map any attribute names, and then it will be configured to Map fname to firstname Map surname to lastname Leave email as is For this, I will create a new IdP Attribute Profile, and assign it to AcmeIdP. Note: if new IdP partners are on boarded later on and are sending the attributes with the same names, it will be possible to assign the existing IdP Attribute Profile to those new partners. Creating the Partner with no Mapping Rules Before configuring OIF/SP to map incoming attributes to local names, we will perform a test Federation SSO to see how attributes look like if left unchanged by OIF/SP. In this case, the IdP partner is bound to an empty IdP Attribute Profile and OIF/SP will not modify the names of the incoming attributes contained in the SSO response. The IdP partner would be configured similarly to (with idp-attribute-profile being the default IdP Attribute Profile, which in our test is empty): When using the Test SP application to do a Federation SSO operation with AcmeIdP, the result of the operation shows that for user alice, the following was sent in the Assertion: NameID set to email address format and value set to alice Attributes sent: email set to alice@oracle.com fname set to Alice surname set to Appleton The XML SAML Response with the Assertion sent back by the IdP is: <samlp:Response ..>    <saml:Issuer ...>http://acme.com/idp</saml:Issuer>    <samlp:Status>        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>    </samlp:Status>    <saml:Assertion ...>        <saml:Issuer ...>http://adc00peq.us.oracle.com:7499/fed/idp</saml:Issuer>        <dsig:Signature ...>        ...        </dsig:Signature>        <saml:Subject>            <saml:NameID ...>alice</saml:NameID>            ...        </saml:Subject>        <saml:Conditions ...>         ...        </saml:Conditions>        <saml:AuthnStatement ...>        ...        </saml:AuthnStatement>        <saml:AttributeStatement ...>            <saml:Attribute Name="email" ...>                <saml:AttributeValue ...>alice@oracle.com</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="surname" ...>                <saml:AttributeValue ...>Appleton</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="fname" ...>                <saml:AttributeValue ...>Alice</saml:AttributeValue>            </saml:Attribute>        </saml:AttributeStatement>    </saml:Assertion></samlp:Response> The Test SP page shows how OIF/SP processed the attributes. Since there are no mapping rules, the names of the attributes were left unchanged. Creating Mapping Rules To create a new IdP Attribute Profile, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Click on the Identity Provider Attribute Profiles tab Click on the “Create IdP Attribute Profile” button Set up the basic information about the new IdP Attribute Profile: Enter a name Enter a description if needed Note about “Ignore Unmapped Attributes”: if checked, OIF/SP will discard any attributes in the SAML/OpenID response not defined in this Attribute Profile. Note about “Default IdP Partner Attribute Profile”: If checked, this will be the pre-assigned IdP Attribute Profile when a new IdP Partner is created via the UI If checked, it will be the IdP Attribute Profile used for IdP partners which do not have an IdP Attribute Profile assigned (for example the ones created via WLST commands) We will now add the necessary mappings. Perform the following operations to add the firstname mapping: Click the Add Entry button in the Attribute Mapping table Set up the email attribute: Message Attribute Name: fname OAM Session Attribute Name: firstname Request from partner: checked (not relevant for SAML) Perform the following operations to add the surname mapping: Click the Add Entry button in the Attribute Mapping table Set up the Name attribute: Message Attribute Name: surname OAM Session Attribute Name: lastname Request from partner: checked (not relevant for SAML) The IdP Attribute Profile has now been configured to map the fname and surname attributes to local names for IdP partners linked to this profile. Note: we do not need to create a mapping for email, since We do not want to change the attribute name We left “Ignore Unmapped Attribute” unchecked. If that box would have been checked, we would have needed to create a mapping for email to email. The IdP Partner will need to be updated to use the new IdP Attribute Profile: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Click on the Search Identity Provider Partners Open the desired IdP Partner In the Attribute Mapping section, select the newly created IdP Attribute Profile  as the Attribute Profile Save Test We are using the Test SP application again to do a Federation SSO operation with OIF using the new IdP Attribute Profile. The XML SAML Response with the Assertion sent back by the IdP is still the same: <samlp:Response ..>    <saml:Issuer ...>http://acme.com/idp</saml:Issuer>    <samlp:Status>        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>    </samlp:Status>    <saml:Assertion ...>        <saml:Issuer ...>http://adc00peq.us.oracle.com:7499/fed/idp</saml:Issuer>        <dsig:Signature ...>        ...        </dsig:Signature>        <saml:Subject>            <saml:NameID ...>alice</saml:NameID>            ...        </saml:Subject>        <saml:Conditions ...>         ...        </saml:Conditions>        <saml:AuthnStatement ...>        ...        </saml:AuthnStatement>        <saml:AttributeStatement ...>            <saml:Attribute Name="email" ...>                <saml:AttributeValue ...alice@oracle.com</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="surname" ...>                <saml:AttributeValue ...>Appleton</saml:AttributeValue>            </saml:Attribute>            <saml:Attribute Name="fname" ...>                <saml:AttributeValue ...>Alice</saml:AttributeValue>            </saml:Attribute>        </saml:AttributeStatement>    </saml:Assertion></samlp:Response> The Test SP page shows different results, since OIF/SP processed the attributes according to the rules where: email was not changed fname was mapped to firstname surname was mapped to lastname Requesting Attributes In this section, I will show how to configure OIF/SP to request attributes from an IdP at runtime by using the OIF WLST commands. The example will be based on a Federation with a remote OpenID 2.0 IdP/OP partner, and the OIF/SP will be configured to: Request the following attributes: Email address with the OpenID attribute name set to http://axschema.org/contact/email and local name set to email UserID with the OpenID attribute name set to http://schemas.openid.net/ax/api/user_id and local name set to userid For this, I will create a new IdP Attribute Profile, and assign it to acmeOP. Later on, if new OP partners are on boarded, it will be possible to assign the existing IdP Attribute Profile so that OIF/SP will request the same attributes from those new IdPs. I will assume that you are already in the WLST environment and connected using: 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() Steps To configure the new IdP Attribute Profile, execute the following steps: Create a new SP Attribute ProfilecreateIdPPartnerAttributeProfile("openIDAttrProfile") Specify the name of the new IdP Attribute Profile Create the mapping for the email attribute and request it at runtimesetIdPPartnerAttributeProfileEntry("openIDAttrProfile", "http://axschema.org/contact/email", "email", requestFromIdP="true") Specify the name of the IdP Attribute Profile to modify Specify the OpenID attribute name to http://axschema.org/contact/email Specify the local name for the attribute: email Indicate that OIF/SP should request it at runtime: requestFromIdP="true" Create the mapping for the email attribute and request it at runtimesetIdPPartnerAttributeProfileEntry("openIDAttrProfile", "http://schemas.openid.net/ax/api/user_id", "userid", requestFromIdP="true") Specify the name of the IdP Attribute Profile to modify Specify the OpenID attribute name to http://schemas.openid.net/ax/api/user_id Specify the local name for the attribute: userid Indicate that OIF/SP should request it at runtime: requestFromIdP="true" To update the IdP partner to use that IdP Attribute Profile, execute: The setIdPPartnerAttributeProfile command:setIdPPartnerAttributeProfile("acmeOP", "openIDAttrProfile") Specify the IdP partner name Specify the name of the IdP Attribute Profile to use OpenID Response The OpenID Response generated by the remote IdP for alice/alice@oracle.com will be: https://acme.com/oam/server/fed/sp/sso?refid=id-TEMxjNN7SEdYWowvioAuTAx7UPuKAUsj-NPWLSUf&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=http%3A%2F%2Fadc00peq.us.oracle.com%3A7499%2Ffed%2Fidp%2Fopenidv20&openid.claimed_id=http%3A%2F%2Fadc00peq.us.oracle.com%3A7499%2Ffed%2Fidp%2Fopenidv20%3Fid%3Did-YxEgHp7b49OrDy9dJP4BWrwbNUQ-&openid.identity=http%3A%2F%2Fadc00peq.us.oracle.com%3A7499%2Ffed%2Fidp%2Fopenidv20%3Fid%3Did-YxEgHp7b49OrDy9dJP4BWrwbNUQ-&openid.return_to=http%3A%2F%2Fadc00pcc.us.oracle.com%3A23002%2Foam%2Fserver%2Ffed%2Fsp%2Fsso%3Frefid%3Did-TEMxjNN7SEdYWowvioAuTAx7UPuKAUsj-NPWLSUf&openid.response_nonce=2014-03-07T22%3A22%3A24Zid-8PQjU4IXHX6inl35bHEFws1Yv-8-&openid.assoc_handle=id-Iek3nx7-n2LldOPeooa4-auWKC4-&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_response&openid.ax.type.attr0=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.value.attr0=alice&openid.ax.type.attr1=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.value.attr1=alice%40oracle.com&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&openid.sig=JBPLV5nDISw4qeWv8Yv4iPGJ6Y8%3D The decoded URL query parameters related to the attributes are: Name of attribute #0: openid.ax.type.attr0= http://schemas.openid.net/ax/api/user_id Value for attribute #0: openid.ax.value.attr0=alice Name of attribute #1: openid.ax.type.attr1= http://axschema.org/contact/email Value for attribute #1: openid.ax.value.attr1=alice@oracle.com The Test SP page shows different results, since OIF/SP processed the attributes according to the rules where: http://schemas.openid.net/ax/api/user_id was mapped to userid http://axschema.org/contact/email was mapped to email In my next article, I will discuss how to use Federation attributes received in SAML/OpenID SSO messages in OAM Authorization Policies and how to provide them to protected web applications.Cheers,Damien Carru

When OIF acts as a Service Provider, it: Validates the incoming SSO response from the IdP Maps the SSO response to an LDAP user record Extracts the user identifier and optional attributes contained in...

Authorization in OIF / IdP

In this article, I will show how to enable and implement Authorization Policies for Federation SSO when OIF is acting as an IdP. When OIF authenticates a user on behalf of remote SAML / OpenID 2.0 partners, it will issue a token (SAML or OpenID) containing information about the user that the partner will consume to identify the user. As a part of the creation of the token, OIF/IdP can be configured to evaluate a Token Issuance Policy that will indicate if the user is allowed to perform Federation SSO with that particular SP/RP. The Token Issuance Policy will be constructed with: The SP Partner Name as the resource One or more constraints The true constraint which is used to indicate that OIF/IdP should issue tokens for all users for the SP partners listed in the policy The Identity constraint made of List of users: OIF/IdP will ensure that the user performing Federation SSO between OIF and the remote SP belongs to that list Or list of groups: OIF/IdP will ensure that the user performing Federation SSO between OIF and the remote SP belongs to a group listed in the constraint Enjoy the reading! Enabling / Disabling Authorization in OIF/IdP Out of the box, Authorization is disabled in OIF/IdP. As such there is no Authorization enforcement when OIF issues a SAML/OpenID token. Note: once authorization is enabled, all IdP Federation SSO operations will require a successful authorization policy evaluation. So if you have existing Federation agreements, no Token Issuance Policy and that you enable authorization, the Federation SSO operation will fail until the required Token Issuance Policies are created. To enable or disable the Authorization in OIF/IdP, you will need to execute the following OIF WLST commands: 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 configureFedSSOAuthz() command: To enable authorization:configureFedSSOAuthz("true") To disable authorization:configureFedSSOAuthz("false") Exit the WLST environment:exit() Token Issuance Policy Overview As mentioned earlier, a Token Issuance Policy is made of two objects: A list of resources, with each resource containing the name of the SP Partner A list of constraints, each constraint being one of the following: The true constraint which is used to indicate that OIF/IdP should issue tokens for all users for the SP partners listed in the policy The Identity constraint made of List of users: OIF/IdP will ensure that the user performing Federation SSO between OIF and the remote SP belongs to that list Or list of groups: OIF/IdP will ensure that the user performing Federation SSO between OIF and the remote SP belongs to a group listed in the constraint Rules using the constraints During a Federation SSO operation, after user authentication, OIF/IdP will check if Authorization is enabled and if yes, it will collect the user’s identity and the groups to which it belongs, the SP Partner name and will invoke OAM Authorization Engine that will indicate whether or not the evaluation was successful: If successful, it means that The SP Partner name was listed as a resource in one in the Token Issuance Policy Evaluation of the constraints for one of the Token Issuance Policies where the SP partner is listed Either a true constraint was present Or an Identity constraint was present With the user’s identity Or with a group to which the user belongs to In the examples listed in this article, we will add all the Token Issuance Policies to the IAM Suite Application Domains in the OAM Administration Console. Test Environment I will showcase usage of the Authorization feature by using examples with: Three users in the LDAP directory used by OIF/IdP (see below for the LDIF output) alice bob charlie Three groups in the LDAP directory Engineers, to which bob and charlie belong Managers, to which alice belongs Employees, to which alice, bob and charlie belong Four SP Partners: OnlineConference.com, HR, TravelSite and 401kSP Three authorization policies Authz #1: only users of group Employees minus bob can access 401kSP Authz #2: only users of group Managers and user charlie can access HR Authz #3: anybody can access TravelSite and OnlineConference.com The LDIF output from the test LDAP directory for the three users is: # alice, users, us.oracle.comdn: cn=alice,ou=users,dc=us,dc=oracle,dc=comobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topgivenName: Aliceuid: alicecn: alicesn: Appletonmail: alice@oracle.com # bob, users, us.oracle.comdn: cn=bob,ou=users,dc=us,dc=oracle,dc=comobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topgivenName: Bobbyuid: bobcn: bobsn: Smithmail: bob@oracle.com # charlie, users, us.oracle.comdn: cn=charlie,ou=users,dc=us,dc=oracle,dc=comobjectClass: personobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: topgivenName: Charlieuid: charliecn: charliesn: Crownmail: charlie@oracle.com The LDIF output from the test LDAP directory for the three groups is: # Managers, groups, us.oracle.comdn: cn=Managers,ou=groups,dc=us,dc=oracle,dc=comuniqueMember: cn=alice,ou=users,dc=us,dc=oracle,dc=comcn: ManagersobjectClass: groupOfUniqueNamesobjectClass: top # Employees, groups, us.oracle.comdn: cn=Employees,ou=groups,dc=us,dc=oracle,dc=comuniqueMember: cn=charlie,ou=users,dc=us,dc=oracle,dc=comuniqueMember: cn=alice,ou=users,dc=us,dc=oracle,dc=comuniqueMember: cn=bob,ou=users,dc=us,dc=oracle,dc=comcn: EmployeesobjectClass: groupOfUniqueNamesobjectClass: top # Engineers, groups, us.oracle.comdn: cn=Engineers,ou=groups,dc=us,dc=oracle,dc=comuniqueMember: cn=bob,ou=users,dc=us,dc=oracle,dc=comuniqueMember: cn=charlie,ou=users,dc=us,dc=oracle,dc=comcn: EngineersobjectClass: groupOfUniqueNamesobjectClass: top Examples Use Case #1 In this use case: 401kSP is the name of the SAML 2.0 SP partner OIF/IdP must allow users belonging to the Employees group to do Federation SSO with that SP Partner OIF/IdP must disallow bob to do Federation SSO with that SP Partner To configure OIF/IdP for this use case, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domains Click Search Click in IAM Suite in the list of results Click on the Token Issuance Policies tab Click “Create Token Issuance Policy” Enter a name (for example EmployeesPolicy) Execute the following steps: Click on Conditions tab Click Add to add a constraint for the employees group Enter the details of the constraints: Name: for example EmployeesGroup Type: Token Requestor Identity Execute the following steps: Click Add Selected Select the newly created constraint to configure it In the conditions details, click Add and select Add Identities Select the Identity Store where user exist Click search Select the Employees Group Execute the following steps: Click Add Selected Execute the following steps: Click Add to add another constraint for user bob Enter the details of the constraints: Name: for example BobUser Type: Token Requestor Identity Execute the following steps: Click Add Selected Select the newly created constraint to configure it In the conditions details, click Add and select Add Identities Select the Identity Store where user exist Click search Select the user bob Execute the following steps: Click Add Selected Execute the following steps: Click on the Rules tab In the Allow Rule section, select the EmployeesGroup condition and add it to the Selected Conditions, since we want to allow users belonging to the Employees group to do Federation SSO with the partners listed in this policy In the Deny Rule section, select the BobUser condition and add it to the Selected Conditions, since we want to disallow bob to do Federation SSO with the partners listed in this policy Click Apply Execute the following steps to create a new resource and add it to the EmployeesPolicy Token Issuance Policy: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domains Click Search Click in IAM Suite in the list of results Click on the Resources tab Click on New Resource and create a new resource for the Token Issuance Policy: Type: TokenServiceRP Resource URL, name of the SP Partner as it was created in the Federation Admin section: 401kSP Operations: all Token Issuance Policy: EmployeesPolicy Apply Use Case #2 In this use case: HR is the name of the SAML 2.0 SP partner OIF/IdP must allow users belonging to the Managers group to do Federation SSO with that SP Partner OIF/IdP must allow charlie to do Federation SSO with that SP Partner To configure OIF/IdP for this use case, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domains Click Search Click in IAM Suite in the list of results Click on the Token Issuance Policies tab Click “Create Token Issuance Policy” Enter a name (for example HRPolicy) Click on Conditions tab Click Add to add a constraint for the employees group Enter the details of the constraints: Name: for example HRCondition Type: Token Requestor Identity Click Add Selected Select the newly created constraint to configure it In the conditions details, click Add and select Add Identities Select the Identity Store where user exist Click search Select the Managers Group and the charlie user Click Add Selected Execute the following steps: Click on the Rules tab In the Allow Rule section, select the HRCondition condition and add it to the Selected Conditions, since we want to allow users belonging to the Managers group and user charlie to do Federation SSO with the partners listed in this policy Click Apply Execute the following steps to create a new resource and add it to the HRPolicy Token Issuance Policy: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domains Click Search Click in IAM Suite in the list of results Click on the Resources tab Click on New Resource and create a new resource for the Token Issuance Policy: Type: TokenServiceRP Resource URL, name of the SP Partner as it was created in the Federation Admin section: HR Operations: all Token Issuance Policy: HRPolicy Apply Use Case #3 In this use case: TravelSite is the name of the first SAML 2.0 SP partner OnlineConference.com is the name of the second SAML 2.0 SP partner OIF/IdP must allow all users to do Federation SSO with those SP Partners To configure OIF/IdP for this use case, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domains Click Search Click in IAM Suite in the list of results Click on the Token Issuance Policies tab Click “Create Token Issuance Policy” Enter a name (for example AllUsersPolicy) Click on Conditions tab Click Add to add a constraint for all the users Enter the details of the constraints: Name: for example TrueCondition Type: True Execute the following steps: Click Add Selected Execute the following steps: Click on the Rules tab In the Allow Rule section, select the TrueCondition condition and add it to the Selected Conditions, since we want to allow all users to do Federation SSO with the partners listed in this policy Click Apply Execute the following steps to create a new resource and add it to the HRPolicy Token Issuance Policy for the TravelSite and OnlineConference.com partners: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domains Click Search Click in IAM Suite in the list of results Click on the Resources tab Click on New Resource and create a new resource for the Token Issuance Policy for TravelSite: Type: TokenServiceRP Resource URL, name of the SP Partner as it was created in the Federation Admin section: TravelSite Operations: all Token Issuance Policy: AllUsersPolicy Apply Click on New Resource and create a new resource for the Token Issuance Policy for OnlineConference.com: Type: TokenServiceRP Resource URL, name of the SP Partner as it was created in the Federation Admin section: OnlineConference.com Operations: all Token Issuance Policy: AllUsersPolicy Apply Summary To view the Resources for the SP Partners created above, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Access Manager -> Application Domains Click Search Click in IAM Suite in the list of results Click on the Resources tab Select TokenServiceRP as the Resource Type Click Search The list of resources of type TokenServiceRP will be displayed MissingRP and UnknownRP are related to OSTS Authorization Policies HR, TravelSite, OnlineConference.com and 401kSP are displayed In the next article, I will be discussing how to configure OIF/SP to map the attribute names from an incoming SSO Assertion to local names, and how to use them in OAM Authorization policies, or how to provide them to protected web applications via HTTP Headers or cookies.Cheers,Damien Carru

In this article, I will show how to enable and implement Authorization Policies for Federation SSO when OIF is acting as an IdP. When OIF authenticates a user on behalf of remote SAML / OpenID 2.0...

Integrating ADFS 2.0/3.0 SP with OIF IdP

As a continuation of my previous articles, I will today describe how to integrate ADFS 2.0/3.0 as an SP and OIF as an IdP. Be sure to have read my previous entry covering the pre-requisites. The SAML 2.0 integration will be based on: Email address will be used as the NameID format The NameID value will contain the user’s email address The HTTP POST binding will be used to send the SAML Assertion to the SP Users will exist in both systems, with each user having the same email address so that it can be used as the common user attribute.ADFS 2.0 is available in Windows 2008 R2, while ADFS 3.0 is available in Windows 2012 R2. The articles will showcase screenshots for ADFS 3.0, while the documented steps will apply to both versions. ADFS Setup To add OIF as an IdP in ADFS SP, perform execute the following steps: Go to the machine where ADFS is deployed If ADFS 2.0 is usedClick Start Menu -> Progams -> Administrative Tools -> AD FS 2.0 ManagementExpand ADFS 2.0 -> Trust RelationshipsIf ADFS 3.0 is usedIn Server Manager, click Tools -> AD FS ManagementExpand AD FS -> Trust RelationshipsRight click on Claims Provider Trusts and select Add Claims Provider Trust The Add Claims Provider Trust window will appear Execute the following steps: Click Start Select Import data about the claims provider from a file Click browse and select the local OIF IdP SAML 2.0 Metadata file (it is required for the OIF endpoints to be SSL terminated, otherwise ADFS will not import the metadata. See my previous pre-requisites article about SSL) Execute the following steps: Click Next If a Warning window appear about unsupported features in ADFS, continue by clicking OK (this relates to the SAML Attribute Authority feature listed in the OIF IdP SAML 2.0 Metadata) Execute the following steps: Enter a name for the new SAML 2.0 Identity Provider Execute the following steps: Click Next A summary window will be displayed Execute the following steps: Click Next Leave Open the Edit Claims box checked Execute the following steps: Click Close The Edit Rule window will appear Execute the following steps: Click Add Rule Select Pass Through or Filter an Incoming Claim Execute the following steps: Click Next Enter a name for the Claim Rule Select NameID as the Incoming Claim Type Select Email as the Incoming name ID format Select Pass through all claim values if you want to accept any email addresses Pass through only claim values that match a specific email suffix value if you want to only accept a specific set of email addresses (in our example, I will select this choice as all users will have an @acme.com email address) Execute the following steps: Click Finish The list of claim rules will be displayed Click OK As mentioned in the pre-requisites article, if you want to configure ADFS to use/accept SHA-1 signatures, perform the following steps (Note: if you don’t configure ADFS to use/accept SHA-1 signatures, you will have to configure OIF to use SHA-256 for signatures): Go to the machine where ADFS is deployed If ADFS 2.0 is usedClick Start Menu -> Progams -> Administrative Tools -> AD FS 2.0 ManagementExpand ADFS 2.0 -> Trust RelationshipsIf ADFS 3.0 is usedIn Server Manager, click Tools -> AD FS ManagementExpand AD FS -> Trust RelationshipsRight click on the newly created Claims Provider Trust and select Properties Select the Advanced Tab Select SHA-1 Click OK OIF Setup To add ADFS as an SP partner in OIF, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the “Create Service Provider Partner” button In the Create screen: Enter a name for the partner Select SAML 2.0 as the Protocol Click Load Metadata and upload the SAML 2.0 Metadata file for the SP Select the NameID format to set in the SAML 2.0 Assertion (Email Address NameID format in this case) Enter how the NameID value will be set: User ID Store Attribute, and mail attribute in this case Select the default Attribute Profile that will indicate how to populate the SAML Assertion with attributes. Click Save As mentioned in the pre-requisites article, if you want to configure OIF to use SHA-256 for signatures, perform the following steps (Note: if you don’t configure OIF to use SHA-256 for signatures, you will have to configure ADFS to use/accept SHA-1 signatures): 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 configureFedDigitalSignature() command:configureFedDigitalSignature(partner="PARTNER_NAME", partnerType="idp/sp", algorithm="SHA-256/SHA-1") Replace PARTNER_NAME with the name of the partner added Set the partnerType to idp or sp Set the algorithm to SHA-256 or SHA-1 An example would be:configureFedDigitalSignature(partner="ADFSSP", partnerType="sp”, algorithm="SHA-256") Exit the WLST environment:exit() Test To test, access the OIF IdP initiated SSO page: URL:http(s)://oam-runtime-host:oam-runtime-port/oamfed/idp/initiatesso?providerid=PARTNER_NAME Replace PARTNER_NAME with the name of the SP partner Example would be:https://acme.com/oamfed/idp/initiatesso?providerid=ADFSSP OAM/OIF will challenge for authentication You will be redirected to ADFS SP with a SAML Assertion In the next article, I will show how to enable and implement Authorization Policies for Federation SSO when OIF is acting as an IdP.Cheers,Damien Carru

As a continuation of my previous articles, I will today describe how to integrate ADFS 2.0/3.0 as an SP and OIF as an IdP. Be sure to have read my previous entry covering the pre-requisites. The SAML...

Integrating ADFS 2.0/3.0 IdP with OIF SP

As a continuation of my previous article, I will today describe how to integrate ADFS 2.0/3.0 as an IdP and OIF as an SP. Be sure to have read my previous entry covering the pre-requisites. The SAML 2.0 integration will be based on: Email address will be used as the NameID format The NameID value will contain the user’s email address The HTTP POST binding will be used to send the SAML Assertion to the SP Users will exist in both systems, with each user having the same email address so that it can be used as the common user attribute. ADFS 2.0 is available in Windows 2008 R2, while ADFS 3.0 is available in Windows 2012 R2. The articles will showcase screenshots for ADFS 3.0, while the documented steps will apply to both versions. ADFS Setup To add OIF as an SP in ADFS IdP, perform execute the following steps: Go to the machine where ADFS 2.0 is deployed If ADFS 2.0 is used Click Start Menu -> Programs -> Administrative Tools -> AD FS 2.0 Management Expand ADFS 2.0 -> Trust Relationships If ADFS 3.0 is used In Server Manager, click Tools -> AD FS Management Expand AD FS -> Trust Relationships Right click on Relying Party Trusts and select Add Relying Party Trust The Add Relying Party Trust window will appear Execute the following steps: Click Start Select Import data about the relying party from a file Click browse and select the OIF SP SAML 2.0 Metadata file from the local machine (it is required for the OIF endpoints to be SSLterminated, otherwise ADFS will not import the metadata. See my previous pre-requisites article about SSL) Execute the following steps: Click Next Enter a name for the new OIF SAML 2.0 Service Provider If using ADFS 3.0, execute the following steps: Click Next The next screen will show an optional multi factor authentication settings section Select the option depending on your requirements Execute the following steps: Click Next Select Permit all users to access this Relying Party Execute the following steps: Click Next A summary window will be displayed Execute the following steps: Click Next Leave Open the Edit Claims box checked Execute the following steps: Click Close The Edit Rule window will appear Execute the following steps: Click Add Rule: we will configure ADFS to retrieve the user’s email address from LDAP and include it as EmailAddress SAML Attribute Select Send LDAP Attributes as Claims Execute the following steps: Click Next Enter a name for the Claim Rule Select Active Directory as the Attribute Store Since we are using Email Address as the NameID, in the first row, select Email Addresses as the LDAP Attribute, and Email Address as the Outgoing Claim Type Execute the following steps: Click Finish The list of rules will be displayed Execute the following steps: Click Add Rule: we will transform the SAML Attribute EmailAddress to make it the NameID with its format set to email address. Select Transform an Incoming Claim Execute the following steps: Click Next Enter a name for the rule Select Email Address as the Incoming Claim Type Select NameID as the Outgoing Claim Type Select Email as the Outgoing name ID format Select Pass through all claim values Execute the following steps: Click Finish The list of claim rules will be displayed Click OK As mentioned in the pre-requisites article, if you want to configure ADFS to use/accept SHA-1 signatures, perform the following steps (Note: if you don’t configure ADFS to use/accept SHA-1 signatures, you will have to configure OIF to use SHA-256 for signatures): Go to the machine where ADFS is deployed If ADFS 2.0 is used Click Start Menu -> Programs -> Administrative Tools -> AD FS 2.0 Management Expand ADFS 2.0 -> Trust Relationships If ADFS 3.0 is used In Server Manager, click Tools -> AD FS Management Expand AD FS -> Trust Relationships Right click on the newly created Relying Party and select Properties Select the Advanced Tab Select SHA-1 Click OK As also mentioned in the pre-requisites article, if you decided to disabled decryption on the ADFS IdP, execute the following steps: Go to the machine where ADFS is deployed If ADFS 2.0 is used, click Start Menu -> Programs -> Administrative Tools -> Windows PowerShell Modules If ADFS 3.0 is used, click Start Menu -> Administrative Tools -> Active Directory Module for Windows PowerShell Execute the following command (replace RP_NAME with the SP name used to create the partner in ADFS):set-ADFSRelyingPartyTrust –TargetName "RP_NAME" –EncryptClaims $False For example:set-ADFSRelyingPartyTrust –TargetName "ACME SP" –EncryptClaims $False OIF Setup To add ADFS as an IdP partner in OIF, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Click on the “Create Identity Provider Partner” button In the Create screen: Enter a name for the partner Check whether or not this partner should be used as the IdP by default when starting a Federation SSO operation, if no IdP partner is specified. (in this example we will set it as the default IdP) Select SAML 2.0 as the Protocol Click Load Metadata and upload the SAML 2.0 Metadata file for the IdP Assertion Mapping section: Optionally set the OAM Identity Store that should be used (note: in the example, I left the field blank to use the default OAM Identity Store) Optionally set the user search base DN (note: in the example, I left the field blank to use the user search base DN configured in the Identity Store) Select how the mapping will occur (note: in the example, I am mapping the Assertion via the NameID to the LDAP mail attribute) Select the Attribute Profile that will be used to map the names of the attributes in the incoming SAML Assertion to local names. See my next article on IdP Attribute Profile for more information. In this example, I will use the default IdP Attribute Profile. Click Save As mentioned in the pre-requisites article, if you want to configure OIF to use SHA-256 for signatures, perform the following steps (Note: if you don’t configure OIF to use SHA-256 for signatures, you will have to configure ADFS to use/accept SHA-1 signatures): 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 configureFedDigitalSignature() command:configureFedDigitalSignature(partner="PARTNER_NAME", partnerType="idp/sp", algorithm="SHA-256/SHA-1") Replace PARTNER_NAME with the name of the partner added Set the partnerType to idp or sp Set the algorithm to SHA-256 or SHA-1 An example would be:configureFedDigitalSignature(partner="ADFSIdP", partnerType="idp", algorithm="SHA-256") Exit the WLST environment:exit() As also mentioned in the pre-requisites article, if you decided not to disable strong encryption on the ADFS IdP, be sure that the JCE Unlimited Strength Jurisdiction policy files were installed in the OIF environment. Test To test the integration: Either protect a resource with WebGate and a FederationScheme with ADFS IdP being the Default SSO Identity Provider for OIF Or use the OIF Test SP application and select ADFS as the IdP In the next article, I will cover the integration between ADFS 2.0/3.0 as an SP and OIF as an IdP.Cheers,Damien Carru

As a continuation of my previous article, I will today describe how to integrate ADFS 2.0/3.0 as an IdP and OIF as an SP. Be sure to have read my previous entry covering the pre-requisites. The SAML 2.0...

Integrating ADFS 2.0/3.0 with OIF: Pre-Requisites

In the next three articles, I will describe how to integrate OIF (11.1.2.2.0 or later) with ADFS 2.0/3.0 for Federation SSO using the SAML 2.0 protocol. The integration will cover: Pre-requisites (this article) ADFS 2.0/3.0 as the IdP and OIF as the SP (read article here) ADFS 2.0/3.0 as the SP and OIF as the IdP (read article here) The SAML 2.0 integration will be based on: Email address will be used as the NameID format The NameID value will contain the user’s email address The HTTP POST binding will be used to send the SAML Assertion to the SP Users will exist in both systems, with each user having the same email address so that it can be used as the common user attribute. ADFS 2.0 is available in Windows 2008 R2, while ADFS 3.0 is availablein Windows 2012 R2. The articles will showcase screenshots for ADFS 3.0, whilethe documented steps will apply to both versions. In this first article, I will discuss the pre-requisites.Pre-Requisites In order to integrate with ADFS using the SAML 2.0 protocol, OAM/OIF must be configured to use HTTPS/SSL as their endpoints. Failure to do so will result in ADFS not accepting the OIF SAML 2.0 Metadata when establishing Federation Trust. When integrating ADFS as an IdP with OIF as an SP, the following points need to be taken into account: By default, ADFS IdP encrypts the SAML Assertion when sending it to the SP using AES-256, and by default the JDK used in the OAM/OIF deployment cannot use strong cryptography such as AES-256. So Either the JDK must be configured for strong cryptography Or ADFS IdP must be configured to disable encryption If ADFS IdP is configured for authentication via HTTP Basic Auth or Windows Native Authentication, then the user can never be logged out as: The HTTP Basic Auth credentials cannot be removed from the browser once entered, unless the browser is closedNote: this applies to other IdPs using HTTP Basic Auth to challenge the user The browser is always logged into ADFS when using Windows Native Authentication By default ADFS requires messages to be signed using SHA-256, while by default OIF uses SHA-1: Either configure ADFS to use/accept SHA-1 Or configure OIF to use SHA-256 for signatures Finally, before integrating OIF and ADFS for SAML 2.0, the metadata for the two servers must have been downloaded. Enabling SSL There are several ways to enable SSL on the public endpoints for OAM/OIF: If a load balancer is fronting OAM/OIF, SSL/HTTPS can be enabled/configured on the load balancer If OHS is fronting OAM/OIF, OHS will be configured for SSL If no component is fronting OAM/OIF, then the WLS server where OAM is running can be configured for SSL/HTTPS Once the component (Load balancer, OHS or WLS) has been configured for SSL, the OAM configuration needs to be updated to reference the new endpoint as its public URL: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Access Manager Settings Set the OAM Server Host to the hostname of the public endpoint Set the OAM Server Post to the SSL port of the public endpoint Set the OAM Server Protocol to https Apply Note: after making those changes, retrieving the OIF SAML 2.0 Metadata will contain the new https URLs Strong Encryption As mentioned, by default, ADFS IdP encrypts the SAML Assertion when sending it to the SP using AES-256 which is considered by Java as a strong cipher (as opposed to “normal strength” such as AES-128, AES-192, 3DES…). Due to legal export reasons, JDK cannot be shipped with strong ciphers enabled in JCE: the administrator/integrator/developer must download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction policy. To update the JCE Unlimited Strength Jurisdiction policy files to support strong encryption such as AES-256, execute the following steps: Determine the major Java version used in the OAM/OIF deployment: Locate the JDK folder used by OAM/OIF Execute:$JDK_HOME/bin/java -version The major version will be printed (either 6 or 7) Download the JCE Unlimited Strength Jurisdiction policy If you are using JDK 7: http://www.oracle.com/technetwork/java/javase/downloads/index.html If you are using JDK 6:http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-java-plat-419418.html Unzip the contents of the downloaded ZIP file to a temporary folder Copy the unzipped local_policy.jar and US_export_policy.jar files your following JDK’s directory (this operation will overwrite the local_policy.jar and US_export_policy.jar files present in that folder):$JDK_HOME/jre/lib/security/ Restart the WLS Servers in the WLS domain to apply the changes To configure ADFS to disable encryption when sending the SAML Assertion to an SP, perform the following steps: Go to the machine where ADFS is deployed If ADFS 2.0 is used, click Start Menu -> Progams -> Administrative Tools -> Windows PowerShell ModulesIf ADFS 3.0 is used, click Start Menu -> Administrative Tools -> Active Directory Module for Windows PowerShell Execute the following command (replace RP_NAME with the SP name used to create the partner in ADFS):set-ADFSRelyingPartyTrust –TargetName “RP_NAME” –EncryptClaims $False ADFS Logout The SAML 2.0 protocol defines a logout profile where each Federation partner involved in a Federation SSO for the current user’s session is notified of the user signing out. This allows the various Federation partners to terminate the user’s session in their SSO domain. ADFS IdP provides different ways to authenticate the user when a Federation SSO is being performed: FORM based authentication where The server will display a login page The user will enter the credentials and submit them HTTP Basic Authentication Where the server will return a 401 status code to the browser The browser will collect the user’s credentials The browser will present the credentials to the ADFS server Note: the browser will keep the credentials and provide them to the ADFS server anytime the browser accesses ADFS, until the browser is closed Integrated Windows Authentication where ADFS leverages the user authentication state in the Windows environment: in this case, since the user is already logged into Windows, the user will be automatically authenticated without any user interaction Let’s look at the effect (or non-effect) of SAML 2.0 logout depending on how the user is authenticated: SP starts a Federation SSO operation with ADFS IdP ADFS IdP needs to authenticate/identify the user If FORM based authentication is used, ADFS displays a login page and the user enter its credentials If HTTP Basic Auth is used, ADFS returns 401 response code, the browser collects the credentials from the user and presents them to ADFS If Integrated Windows Authentication is used, the browser will get automatically a Kerberos/NTLMSSP token from the Windows Domain Controller / KDC that it will present to the ADFS server. There is no user interaction. User is redirected to SP with a SAML Assertion User initiates SAML 2.0 logout from the SP SP redirects the user to ADFS IdP for SAML 2.0 Logout ADFS clears cookies from the user’s browser (but not cached HTTP Basic Auth credentials if used previously) Logout is done In the same browser, SP starts a Federation SSO operation with ADFS IdP ADFS IdP needs to authenticate/identify the user If FORM based authentication is used, ADFS displays a login page and the user enter its credentials: user is challenged and needs to provide its credentials If HTTP Basic Auth is used, ADFS returns 401 response code, the browser cached the credentials collected earlier and thus automatically presents them to ADFS. There is no user interaction If Integrated Windows Authentication is used, the browser will get automatically a Kerberos/NTLMSSP token from the Windows Domain Controller / KDC that it will present to the ADFS server. There is no user interaction. So if HTTP Basic Auth or Integrated Windows Authentication is used as the authentication mechanism at ADFS 2.0 IdP, after a logout, the user will still be “logged in” at the IdP, and executing a new Federation SSO will not trigger the user being challenged and will result with the user being automatically authenticated at the SP, after Federation SSO is done. Important note: the behavior seen with logout also applies to other IdPs (OIF for example), that are using HTTP Basic Auth as the authentication mechanism I will discuss SAML 2.0 Federation logout in a future article. SAML 2.0 Metadata To download the SAML 2.0 Metadata from the ADFS 2.0/3.0 server: Open a browser Go to the ADFS 2.0/3.0 Metadata publishing service:https://adfs-host:adfs-port/FederationMetadata/2007-06/FederationMetadata.xml Save the Metadata locally using the Save As button in the browser To download the SAML 2.0 Metadata from OIF: Open a browser Go to the OIF  Metadata publishing service:http(s)://oam-runtime-host:oam-runtime-port/oamfed/idp/metadataor http(s)://oam-runtime-host:oam-runtime-port/oamfed/sp/metadata Save the Metadata locally using the Save As button in the browser Note: be sure to have enabled SSL in OAM first before download the OIF metadata, as the metadata will contain the OAM/OIF URLs. SHA-256 vs SHA-1 After having setting up Federation between OIF and ADFS, you will need to: Either configure ADFS 2.0 to use/accept SHA-1 Or configure OIF to use SHA-256 for signatures In the next article, I will cover the integration between ADFS as an IdP and OIF as an SP.Cheers,Damien Carru

In the next three articles, I will describe how to integrate OIF (11.1.2.2.0 or later) with ADFS 2.0/3.0 for Federation SSO using the SAML 2.0 protocol. The integration will cover: Pre-requisites (this...

Using Test SP App in OIF/ SP

In this article, I will talk about how to enable and use the Test SP Application in OIF/SP, which is very useful when OIF is an SP and Federation agreements are set up. It provides the following capabilities: Test the Federation SSO flows Verify if the mapping rules work See which attributes are sent by the IdP, how they are named and how they are processed by OIF/SP See the Federation token (SAML Assertion or OpenID SSO Response) This tool is very useful to diagnose issues in the SAML/OpenID flows, before rolling Federation SSO out. This is a Web Application that will exercise the SP functionality of OIF via a browser without creating any OAM session: The application is accessed via a browser Federation SSO is started with the specified IdP You authenticate at the IdP OIF/SP processes the SAML Assertion / OpenID SSO response The application displays the result and SAML Assertion / OpenID SSO response Enabling / Disabling the Test SP Engine Out of the box, the Test SP application is disabled and you will need to enable it before being able to use it. Note: once you’re done using the Test SP App, you should disable it. To enable or disable the Test SP app, you will need to execute the following OIF WLST commands: 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 configureTestSPEngine() command: To enable the Test SP Engine:configureTestSPEngine("true") To disable the Test SP Engine:configureTestSPEngine("false") Exit the WLST environment:exit() Using the Test SP Engine Starting Federation SSO Starting the Federation SSO flow involves: Going to the Test SP application via a browser Selecting the IdP to perform Federation SSO with Start the operation The URL to use to access the Test SP application is:http(s)://oam-runtime-host:oam-runtime-port/oamfed/user/testspsso The Test SP application will display a drop down with a list of IdPs to perform Federation SSO with: Either you select an IdP Or you choose the one references as the Default, which will instruct OIF/SP to use the Default SSO IdP Once you select the IdP, click on the “Start SSO” button that will trigger the Federation SSO with the specified IdP: You will be redirected to the IdP, similarly to a normal Federation SSO operation (the IdP will not be aware that you are using the Test SP application bundled with OIF: the IdP is only aware that OIF/SP is performing the Federation SSO) The IdP will either: Challenge you for your credentials, and then send a SAML/OpenID response Send an SAML/OpenID response (either because you are already authenticated, or because an error occurred) Result of the Test SP Operation When the IdP redirects the user with the SAML Assertion / OpenID Response to OIF/SP, the server will validate the response, map it to an LDAP user record and return the result to the Test SP application which will display: The result of the authentication operation The canonical user ID to which the response was mapped which contains The Identity Store name The user’s DN The user’s ID The authentication instant The IdP partner name Attributes from the SSO Response that will be stored in the OAM session (see my next article for more information) The decrypted/decoded SSO response Diagnosing Issues If the Federation SSO between an IdP and OIF/SP is not working, the Test SP engine can be a good tool with the OAM/OIF logs to diagnose the problems. Mapping Issues If the incoming SSO Assertion cannot be mapped to a local LDAP user record, the Test SP application can show: The error message The NameID/attributes sent by the IdP The SSO message sent by the IdP, which contains the NameID/attributes In this example, the IdP’s and OIF/SP’s administrators agreed to use SAML 2.0 and identify the user via the email address. The issue here is that the email address for alice at the IdP is alice.appleton@oralce.com, while in the LDAP directory used by OIF/SP, the email is alice@oracle.com The Test SP application will show the following information at the end of the flow: The authentication operation failed The Assertion could not be mapped to a local user record The data extracted from the Assertion as well as the message itself The OIF log files will show the following error message as well as the SAML message: <Feb 28, 2014 7:18:05 AM PST> <Warning> <oracle.security.fed.eventhandler.fed.profiles.sp.sso.assertion.Saml20AssertionProcessor> <FED-15108> <User was not found during attribute based authentication using NameID mapping for name identifier: alice.appleton@oracle.com name identifier format : urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress and message : <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http://adc00pcc.us.oracle.com:23002/oam/server/fed/sp/sso" ID="id-aWfL5-f37nhQWh0WWjHbobsVetM-" InResponseTo="id-hqkZGMV-wEO5-CulpYxArIvr91Y14dA-WSRYZ8zP" IssueInstant="2014-02-28T15:18:05Z" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://adc00peq.us.oracle.com:7499/fed/idp</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="id-PoOD-BDUeoiSY4ajPCQ86yjZWkw-" IssueInstant="2014-02-28T15:18:05Z" Version="2.0"><saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://adc00peq.us.oracle.com:7499/fed/idp</saml:Issuer><dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><dsig:Reference URI="#id-PoOD-BDUeoiSY4ajPCQ86yjZWkw-"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><dsig:DigestValue>X5ojFxrpBOS4klosM5jcBOF8Bqg=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>VJKJOBOowHZ4lVkHjX4w2YHi+0ZAa4ez/+D+ketAQcOxxtwOZPcBYERwkMgazudMh0XEMbIkwsBTVwb4tX+uV327Gjlp1hXc0uYnm2n8mZfen9Ppru6jTES4N7PoD3mOpCfFEHBUJg118DihWGLfzBWw7LMLaN2A+dMhQwBMXAw=</dsig:SignatureValue></dsig:Signature><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">alice.appleton@oracle.com</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData InResponseTo="id-hqkZGMV-wEO5-CulpYxArIvr91Y14dA-WSRYZ8zP" NotOnOrAfter="2014-02-28T15:23:05Z" Recipient="http://adc00pcc.us.oracle.com:23002/oam/server/fed/sp/sso"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore="2014-02-28T15:18:05Z" NotOnOrAfter="2014-02-28T15:23:05Z"><saml:AudienceRestriction><saml:Audience>http://adc00pcc.us.oracle.com:23002/oam/fed</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2014-02-28T15:18:05Z" SessionIndex="id-2i7BY1gGnhukoBSDmrvkBIaG-NI-" SessionNotOnOrAfter="2014-02-28T16:18:05Z"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement></saml:Assertion></samlp:Response>.> Response Validation Issues If the incoming SSO Assertion cannot be validated, the Test SP application can show: The error message The SSO message sent by the IdP In this example, the IdP’s and OIF/SP’s administrators agreed to use SAML 2.0 but the IdP is not signing the Assertion as required by OIF/SP (typically the Assertion is signed: for this example I disabled the signature on the IdP to showcase the error) The Test SP application will show the following information at the end of the flow: The authentication operation failed The Assertion could not be validated The SAML message The OIF log files will show the following error message as well as the SAML message: <Feb 28, 2014 7:23:05 AM PST> <Error> <oracle.security.fed.eventhandler.fed.profiles.utils.CheckUtils> <FEDSTS-18003> <Assertion is not signed.><Feb 28, 2014 7:23:05 AM PST> <Error> <oracle.security.fed.eventhandler.fed.profiles.sp.sso.v20.ProcessResponseEventHandler> <FED-18012> <Assertion cannot be validated: <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http://adc00pcc.us.oracle.com:23002/oam/server/fed/sp/sso" ID="id-De7M27k5CWpBsuGzgaxwHgwqV1g-" InResponseTo="id-fX4nHKLCMcA-ZjHvsKfCORDZLmIDcQMpVYjqmxQb" IssueInstant="2014-02-28T15:23:05Z" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://adc00peq.us.oracle.com:7499/fed/idp</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="id-EAdQSXj-royYNuuWbaBWZVdBtu8-" IssueInstant="2014-02-28T15:23:05Z" Version="2.0"><saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://adc00peq.us.oracle.com:7499/fed/idp</saml:Issuer><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">alice@oracle.com</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData InResponseTo="id-fX4nHKLCMcA-ZjHvsKfCORDZLmIDcQMpVYjqmxQb" NotOnOrAfter="2014-02-28T15:28:05Z" Recipient="http://adc00pcc.us.oracle.com:23002/oam/server/fed/sp/sso"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore="2014-02-28T15:23:05Z" NotOnOrAfter="2014-02-28T15:28:05Z"><saml:AudienceRestriction><saml:Audience>http://adc00pcc.us.oracle.com:23002/oam/fed</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2014-02-28T15:23:05Z" SessionIndex="id--0QWpaU2AV-L7UpNvLH5Bn7Z5Xk-" SessionNotOnOrAfter="2014-02-28T16:23:05Z"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement></saml:Assertion></samlp:Response>.> In the next article, I will describe how to integrate OIF (11.1.2.2.0 or later) with ADFS 2.0 for Federation SSO using the SAML 2.0 protocol.Cheers,Damien Carru

In this article, I will talk about how to enable and use the Test SP Application in OIF/SP, which is very useful when OIF is an SP and Federation agreements are set up. It provides the following...

Create SAML 1.1 / OpenID 2.0 IdP Partners in OIF/ SP

This article is a continuation of my previous entry where I discussed how to create SAML 2.0 IdP Partners in OIF/SP. In this article, I will cover how to set up a Federation agreement between OIF acting as an SP and a remote IdP Partner via the SAML 1.1 or OpenID 2.0 protocols: Set up a remote SAML 1.1 IdP Partner Set up a remote OpenID 2.0 IdP Partner The article will describe how to perform the above tasks either via the UI, or via the use of the OIF WLST commands. Introduction Be sure to read my previous article where I described: Establishing Federation Trust Assertion Mapping SAML 1.1 OAM Administration Console To create a new SAML 1.1 IdP Partner, execute the following steps (ensure first that you have all the data from the IdP partner, such as certificates, IdP identifiers and URLs): Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Click on the "Create Identity Provider Partner" button In the Create screen: Enter a name for the partner Enter the Issuer / ProviderID of the IdP Partner If the SuccinctID is left blank, OIF/SP will compute it by digesting the Provider ID using the SHA-1 algorithm (should be left blank) Enter the SSO Service URL for that IdP Partner: this is the URL where the user will be redirected from OIF/SP with a SAML AuthnRequest to the IdP. If the partner supports the SAML 2.0 Artifact protocol, enter the SOAP Service URL where OIF/SP will connect to retrieve the SAML Assertion during an SSO Artifact operation Upload the IdP Signing Certificate file: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding Assertion Mapping section: Optionally set the OAM Identity Store that should be used (note: in the example, I left the field blank to use the default OAM Identity Store) Optionally set the user search base DN (note: in the example, I left the field blank to use the user search base DN configured in the Identity Store) Select how the mapping will occur (note: in the example, I am mapping the Assertion via the NameID to the LDAP mail attribute) Select the Attribute Profile that will be used to map the names of the attributes in the incoming SAML Assertion to local names. See my next article on IdP Attribute Profile for more information. In this example, I will use the default IdP Attribute Profile. Click Save After the partner is created, the "Edit Partner" screen will be shown with: The settings set in the previous screen modifiable An Advanced Settings section displayed: HTTP Basic Authentication: if the Artifact binding is used, OIF/SP will need to connect to the IdP directly over SOAP to retrieve the SAML Assertion. Sometimes the IdP will enable HTTP Basic Authentication on the SOAP channel, and OIF/SP will need to provide username/password to the IdP (those credentials will be agreed between the IdP’s and SP’s administrators). WLST To create a new SAML 1.1 IdP Partner using the OIF WLST commands, execute the following steps (ensure first that you have all the data from the IdP partner, such as certificates, IdP identifiers and URLs): 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() Create SAML 1.1 IdP Partner that will be called acmeIdP in OIF:addSAML11IdPFederationPartner("acmeIdP", "https://acme.com/idp", "https://acme.com/saml11/sso", "https://acme.com/saml11/soap") By default, the new SP partner will be configured to: Use the default OAM Identity Store Use the user search base DN of the Identity Store (not overridden) Map the SAML Assertion using the NameID, matching the LDAP mail attribute Use the default Identity Provider Attribute Profile No certificate has been uploaded for this IdP partner Exit the WLST environment:exit() Modifying Federation Settings via WLST In this section, I will list how to change the common IdP Partner settings via the OIF WLST commands: SAML Assertion Mapping settings OAM Identity Store and User Search Base DN for SAML Assertion Mapping SAML Signing Certificate IdP Partner Attribute Profile for an IdP Partner I will assume that you are already in the WLST environment and connected using: 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() SAML Assertion Mapping settings To configure mapping settings for a SAML IdP Partner: Use the following command to map the Assertion via the NameID:setIdPPartnerMappingNameID(partnerName, userstoreAttr) partnerName is the name that was used to create the IdP Partner userstoreAttr: LDAP user attribute to match the NameID value. Use the following command to map the Assertion via a SAML Attribute:setIdPPartnerMappingAttribute(partnerName, assertionAttr, userstoreAttr) partnerName is the name that was used to create the IdP Partner assertionAttr: name of the SAML Attribute. userstoreAttr: LDAP user attribute to match the SAML Attribute value. Use the following command to map the Assertion via an LDAP query:setIdPPartnerMappingAttributeQuery(partnerName, attrQuery) partnerName is the name that was used to create the IdP Partner attrQuery: the LDAP query to be used (for example (&(givenname=%firstname%)(sn=%lastname%))). OAM Identity Store and User Search Base DN To configure OIF/SP to use a specific OAM Identity Store and/or a specific User Search Base DN when mapping the incoming SAML Assertion, execute the following command setPartnerIDStoreAndBaseDN(): Use the following command to set the OAM Identity Store only:setPartnerIDStoreAndBaseDN(partnerName, "idp", storeName="oid") partnerName is the name that was used to create the IdP Partner idp indicates the partner type storeName: references the OAM Identity Store to use Use the following command to set the Search Base DN only:setPartnerIDStoreAndBaseDN(partnerName, "idp", searchBaseDN="ou=managers,dc=acme,dc=com") partnerName is the name that was used to create the IdP Partner idp indicates the partner type searchBaseDN: indicates the search base DN to use Use the following command to set the OAM Identity Store and Search Base DN:setPartnerIDStoreAndBaseDN(partnerName, "idp", storeName="oid", searchBaseDN="ou=managers,dc=acme,dc=com") partnerName is the name that was used to create the IdP Partner idp indicates the partner type storeName: references the OAM Identity Store to use searchBaseDN: indicates the search base DN to use Use the following command to remove the OAM Identity Store and Search Base DN from the IdP partner entry:setPartnerIDStoreAndBaseDN(partnerName, "idp", delete="true") partnerName is the name that was used to create the IdP Partner idp indicates the partner type SAML Signing Certificate There are various WLST commands available to manage signing and encryption certificates: getFederationPartnerSigningCert() which prints the partner’s signing certificate in Base64 encoded format:getFederationPartnerSigningCert("acmeIdP", "idp") With acmeIdP being the name of partner created earlier idp indicates the partner type setFederationPartnerSigningCert() which uploads the signing certificate file passed as a parameter to the IdP Partner configuration:setFederationPartnerSigningCert("acmeIdP", "idp", "/tmp/cert.file") With acmeIdP being the name of partner created earlier idp indicates the partner type the third parameter indicates the location on the file system of the file containing the certificate: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding deleteFederationPartnerSigningCert() which removes the signing certificate from the IdP partner entry:deleteFederationPartnerSigningCert("acmeIdP", "idp") With acmeIdP being the name of partner created earlier idp indicates the partner type IdP Partner Attribute Profile To configure the IdP Partner Attribute Profile for a specific IdP Partner, use the following commands: To configure an IdP Partner to use a specific IdP Partner Attribute Profile, execute:setIdPPartnerAttributeProfile(partnerName, attrProfileID) partnerName is the name that was used to create the IdP Partner attrProfileID is the IdP Partner Attribute Profile ID To list the existing the IdP Partner Attribute Profiles, execute:listIdPPartnerAttributeProfileIDs() Examples The below commands could be used to add a SAML 1.1 IdP partner (in this example I chose to specify an Identity Store): addSAML11IdPFederationPartner("acmeIdP", "https://acme.com/idp", "https://acme.com/saml11/sso", "https://acme.com/saml11/soap")setFederationPartnerSigningCert("acmeIdP", "idp", "/tmp/acme-idp-cert.pem")setPartnerIDStoreAndBaseDN("acmeIdP", "idp", "oid")setIdPPartnerMappingNameID("acmeIdP", "mail") OpenID 2.0 OAM Administration Console To create a new OpenID 2.0 IdP/OP Partner, execute the following steps (ensure first that you have all the data from the IdP/OP partner, such as discovery and SSO URLs): Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Click on the "Create Identity Provider Partner" button In the Create screen: Enter a name for the partner Select OpenID 2.0 as the Protocol Select how to interact with the OpenID OP Either by specifying the OpenID Discovery URL where the OP’s XRDS is published Or by specifying the OpenID SSO URL where the user should be redirected for OpenID SSO Enter the URL corresponding to the Service Details choice Mapping section: Optionally set the OAM Identity Store that should be used (note: in the example, I left the field blank to use the default OAM Identity Store) Optionally set the user search base DN (note: in the example, I left the field blank to use the user search base DN configured in the Identity Store) Select how the mapping will occur (note: in the example, I am mapping the OpenID Response via an attribute called http://axschema.org/contact/email to the LDAP mail attribute) Note: Mapping via NameID is not possible with the OpenID protocol Select the Attribute Profile that will be used to map the names of the attributes in the incoming SAML Assertion to local names. See my next article on IdP Attribute Profile for more information. In this example, I will use the default IdP Attribute Profile. Click Save After the partner is created, the "Edit Partner" screen will be shown with: The settings set in the previous screen modifiable An Advanced Settings section displayed: Enable OpenID UI Extension: indicates to the OIF/SP/RP to include in the OpenID request the UI Extension and set the mode to popup, if supported by the OP. OpenID UI Extension Language Preference: indicates to the OIF/SP/RP to include in the OpenID request the UI Extension and set the language field to the Accept-Language HTTP header value sent by the user’s browser, if supported by the OP. Enable OpenID UI Extension Relying Party Icon: indicates to the OIF/SP/RP to include in the OpenID request the UI Extension and set the icon flag, if supported by the OP. The OpenID 2.0 protocol mainly relies on user attributes being shared between the OP and the RP during the OpenID 2.0 SSO exchange. OIF/RP can map the names of the attributes in the incoming SSO response to local names, and this is done via the IdP Attribute Profile. In my next article, I will be explaining how the SP can be configured for attribute name mapping. WLST To create a new OpenID 2.0 OP Partner using the OIF WLST commands, execute the following steps (ensure first that you have all the data from the OP partner, such as IdP/OP realm and URLs): 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() Create OpenID 2.0 OP Partner that will be called acmeOP in OIF:addOpenID20IdPFederationPartner("acmeOP", "https://acme.com/openid/sso", "https://acme.com/openid/xrds") By default, the new SP partner will be configured to: Use the default OAM Identity Store Use the user search base DN of the Identity Store (not overridden) Assertion Mapping will not be configured Use the default Service Provider Attribute Profile Exit the WLST environment:exit() Modifying Federation Settings via WLST In this section, I will list how to change the common IdP/OP Partner settings via the OIF WLST commands: OpenID SSO Response Mapping settings OAM Identity Store and User Search Base DN for OpenID SSO Response IdP Partner Attribute Profile for an IdP Partner I will assume that you are already in the WLST environment and connected using: 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() OpenID SSO Response Mapping settings To configure mapping settings for an OpenID IdP Partner: Use the following command to map the SSO Response via a SAML Attribute:setIdPPartnerMappingAttribute(partnerName, assertionAttr, userstoreAttr) partnerName is the name that was used to create the IdP Partner assertionAttr: name of the OpenID Attribute. userstoreAttr: LDAP user attribute to match the SAML Attribute value. Use the following command to map the SSO Response via an LDAP query:setIdPPartnerMappingAttributeQuery(partnerName, attrQuery) partnerName is the name that was used to create the IdP Partner attrQuery: the LDAP query to be used (for example (&(givenname=%firstname%)(sn=%lastname%))). OAM Identity Store and User Search Base DN To configure OIF/SP to use a specific OAM Identity Store and/or a specific User Search Base DN when mapping the incoming OpenID SSO Response, execute the following command setPartnerIDStoreAndBaseDN(): Use the following command to set the OAM Identity Store only:setPartnerIDStoreAndBaseDN(partnerName, "idp", storeName="oid") partnerName is the name that was used to create the IdP Partner idp indicates the partner type storeName: references the OAM Identity Store to use Use the following command to set the Search Base DN only:setPartnerIDStoreAndBaseDN(partnerName, "idp", searchBaseDN="ou=managers,dc=acme,dc=com") partnerName is the name that was used to create the IdP Partner idp indicates the partner type searchBaseDN: indicates the search base DN to use Use the following command to set the OAM Identity Store and Search Base DN:setPartnerIDStoreAndBaseDN(partnerName, "idp", storeName="oid", searchBaseDN="ou=managers,dc=acme,dc=com") partnerName is the name that was used to create the IdP Partner idp indicates the partner type storeName: references the OAM Identity Store to use searchBaseDN: indicates the search base DN to use Use the following command to remove the OAM Identity Store and Search Base DN from the IdP partner entry:setPartnerIDStoreAndBaseDN(partnerName, "idp", delete="true") partnerName is the name that was used to create the IdP Partner idp indicates the partner type IdP Partner Attribute Profile To configure the IdP Partner Attribute Profile for a specific IdP Partner, use the following commands: To configure an IdP Partner to use a specific IdP Partner Attribute Profile, execute:setIdPPartnerAttributeProfile(partnerName, attrProfileID) partnerName is the name that was used to create the IdP Partner attrProfileID is the IdP Partner Attribute Profile ID To list the existing the IdP Partner Attribute Profiles, execute:listIdPPartnerAttributeProfileIDs() Examples The below commands could be used to add an OpenID 2.0 OP partner (in this example I chose not to specify an Identity Store): addOpenID20IdPFederationPartner("acmeOP", "https://acme.com/openid/sso", "https://acme.com/openid/xrds")setIdPPartnerMappingAttribute("acmeOP", "http://axschema.org/contact/email", "mail") OpenID for Google / Yahoo OIF administration tools provide an easy way to add Google or Yahoo as an OpenID 2.0 OP/IdP. OIF will create the necessary artifacts to perform Federation SSO with Google or Yahoo via the OpenID protocol For Google: OIF will request the country, mail, firstname, lastname and language attributes The SSO response mapping will be done via the mail attribute For Yahoo OIF will request the country, mail, firstname, lastname, gender and language attributes The SSO response mapping will be done via the mail attribute OAM Administration Console To create Google or Yahoo as a new OpenID 2.0 IdP/OP Partner, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Click on the "Create Identity Provider Partner" button In the Create screen: Enter a name for the partner Select OpenID 2.0 as the Protocol Select "Google provider default settings" if you want to add Google "Yahoo provider default settings" if you want to add Yahoo Save WLST To create Google or Yahoo as a new OpenID 2.0 IdP/OP Partner using the OIF WLST commands, execute the following steps: 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() Create OpenID 2.0 OP Partner: For Google (the partner name will be google):addOpenID20GoogleIdPFederationPartner() For Yahoo (the partner name will be yahoo):addOpenID20YahooIdPFederationPartner() In the next article, I will talk about how to enable and use the Test SP Application in OIF/SP, which is very useful when OIF is an SP and Federation agreements are set up.Cheers,Damien Carru

This article is a continuation of my previous entry where I discussed how to create SAML 2.0 IdP Partners in OIF/SP. In this article, I will cover how to set up a Federation agreement between OIF...

Create SAML 2.0 IdP Partners in OIF/ SP

After having discussed in previous articles how to manage OIF/IdP, I will cover the administration of OIF/SP. In this post, I will explain how to set up a Federation agreement between OIF acting as a SAML 2.0 SP and a remote SAML 2.0 IdP Partner, including: Set up a remote SAML 2.0 IdP Partner with SAML 2.0 Metadata Set up a remote SAML 2.0 IdP Partner without SAML 2.0 Metadata Configuring OIF/SP to map an incoming SAML Assertion to an LDAP user The article will describe how to perform the above tasks either via the UI, or via the use of the OIF WLST commands. Enjoy the reading! Establishing Federation Trust Establishing Trust between Federation partners is a pre-requisite before being able to perform any Federation SSO operation between the Federation servers. Trust establishment involves exchanging certificate information, if the protocol used relies on PKI X.509 certificates to secure message exchanges, as well as the locations/URLs of the services implementing the federation protocol. Assertion Mapping With OIF acting as a Service Provider and delegating user authentication to a remote IdP, the administrator will need to agree with the IdP’s administrator how the user will be identified in the SAML Assertion (user information stored in the NameID, or as a SAML Attribute, or in several SAML Attributes..), and then OIF/SP will need to be configured to map the incoming SAML Assertion to an LDAP user record, using the NameID and/or SAML Attribute(s). Note: OAM requires the incoming Assertion to be mapped to an LDAP user record in order to create an OAM session. OIF/SP can map an incoming SAML Assertion to an LDAP user record via: The SAML Assertion NameID, mapped to an attribute in the LDAP user record: in this case, OIF/SP will perform an LDAP lookup for a single LDAP user record whose value for the attribute specified in the mapping matches the value of the SAML NameID. A SAML Attribute from the Assertion, mapped to an attribute in the LDAP user record: in this case, OIF/SP will perform an LDAP lookup for a single LDAP user record whose value for the attribute specified in the mapping matches the value of the specified SAML Attribute. The use of an LDAP query that will contain data from the SAML Assertion: The LDAP query will be specified by the administrator The data from the Assertion will be identified in the LDAP query as %NAME%, with NAME being: Either the name of a SAML Attribute from the Assertion Or the NameID: in this case, NAME will be replaced by fed.nameidvalue Examples of LDAP queries would be: (mail=%email%) that will result in an LDAP lookup for a single LDAP user record whose value for the mail attribute matches the value of the email SAML Attribute (&(givenname=%firstname%)(sn=%lastname%)) that will result in an LDAP lookup for a single LDAP user record whose values for the givenname attribute and sn attribute matche the values of the firstname and lastname SAML Attributes (&(title=manager)(uid=%fed.nameidvalue%)) that will result in an LDAP lookup for a single LDAP user record whose value for the uid attribute matches the value of the NameID, and whose title attribute is equals to manager OIF/SP also provides the capabilities to use a specific Identity Store and user search base DN when mapping the Assertion to an LDAP user record. This is optional, and: If no specific Identity Store is specified in the Assertion Mapping rules, then the default OAM Identity Store will be used If no specific user search base DN is specified in the Assertion Mapping rules, then the user search base DN configured in the Identity Store will be used SAML 2.0 with Metadata OAM Administration Console To create a new SAML 2.0 IdP Partner with Metadata, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Click on the “Create Identity Provider Partner” button In the Create screen: Enter a name for the partner Check whether or not this partner should be used as the IdP by default when starting a Federation SSO operation, if no IdP partner is specified. Select SAML 2.0 as the Protocol Click Load Metadata and upload the SAML 2.0 Metadata file for the IdP Assertion Mapping section: Optionally set the OAM Identity Store that should be used (note: in the example, I left the field blank to use the default OAM Identity Store) Optionally set the user search base DN (note: in the example, I left the field blank to use the user search base DN configured in the Identity Store) Select how the mapping will occur (note: in the example, I am mapping the Assertion via the NameID to the LDAP mail attribute) Select the Attribute Profile that will be used to map the names of the attributes in the incoming SAML Assertion to local names. See my next article on IdP Attribute Profile for more information. In this example, I will use the default IdP Attribute Profile. Click Save After the partner is created, the “Edit Partner” screen will be shown with: The settings set in the previous screen modifiable An Advanced Settings section displayed: Enable Global Logout, indicating whether or not OIF should execute the SAML 2.0 Logout exchange with the partner as part of the logout process. HTTP POST SSO Response Binding: indicates how the OIF/SP will request the IdP to send the Assertion back to the SP. If checked, OIF/SP will request the IdP to send the Assertion using the HTTP-POST binding, otherwise will request the Artifact binding. HTTP Basic Authentication: if the Artifact binding is used, OIF/SP will need to connect to the IdP directly over SOAP to retrieve the SAML Assertion. Sometimes the IdP will enable HTTP Basic Authentication on the SOAP channel, and OIF/SP will need to provide username/password to the IdP (those credentials will be agreed between the IdP’s and SP’s administrators). Authentication Request NameID Format: indicates if OIF/SP should request via the SAML AuthnRequest a specific NameID to be used. If set to None, OIF/SP won’t request anything and the IdP will select the NameID format that was agreed upon out of band. If you set a value, be sure that it corresponds to what was agreed upon between the IdP’s and SP’s administrators. (Can be left blank) WLST To create a new SAML 2.0 IdP Partner with Metadata using the OIF WLST commands, execute the following steps: 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() Create SAML 2.0 IdP Partner with Metadata that will be called acmeIdP in OIF:addSAML20IdPFederationPartner("acmeIdP", "/tmp/acme-idp-metadata-saml20.xml") By default, the new IdP partner will be configured to: Use the default OAM Identity Store Use the user search base DN of the Identity Store (not overridden) Map the SAML Assertion using the NameID, matching the LDAP mail attribute Set the Authentication Request NameID Format to None Use HTTP-POST as the Default SSO Response Binding Use the default Identity Provider Attribute Profile Exit the WLST environment:exit() SAML 2.0 without Metadata OAM Administration Console To create a new SAML 2.0 IdP Partner without Metadata, execute the following steps (ensure first that you have all the data from the IdP partner, such as certificates, IdP identifiers and URLs): Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Service Provider Administration Click on the “Create Identity Provider Partner” button In the Create screen: Enter a name for the partner Check whether or not this partner should be used as the IdP by default when starting a Federation SSO operation, if no IdP partner is specified. Select SAML 2.0 as the Protocol Select Enter Manually Enter the Issuer / ProviderID of the IdP Partner If the SuccinctID is left blank, OIF/SP will compute it by digesting the Provider ID using the SHA-1 algorithm (should be left blank) Enter the SSO Service URL for that IdP Partner: this is the URL where the user will be redirected from OIF/SP with a SAML AuthnRequest to the IdP. If the partner supports the SAML 2.0 Artifact protocol, enter the SOAP Service URL where OIF/SP will connect to retrieve the SAML Assertion during an SSO Artifact operation If the partner supports the SAML 2.0 Logout protocol: Enter the SAML 2.0 Logout Request URL where the partner can process a SAML 2.0 LogoutRequest message Enter the SAML 2.0 Logout Response URL where the partner can process a SAML 2.0 LogoutResponse message Upload the IdP Signing Certificate file: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding If the IdP has an Encryption Certificate, upload the file: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding Assertion Mapping section: Optionally set the OAM Identity Store that should be used (note: in the example, I left the field blank to use the default OAM Identity Store) Optionally set the user search base DN (note: in the example, I left the field blank to use the user search base DN configured in the Identity Store) Select how the mapping will occur (note: in the example, I am mapping the Assertion via the NameID to the LDAP mail attribute) Select the Attribute Profile that will be used to map the names of the attributes in the incoming SAML Assertion to local names. See my next article on IdP Attribute Profile for more information. In this example, I will use the default IdP Attribute Profile. Click Save After the partner is created, the “Edit Partner” screen will be shown with: The settings set in the previous screen modifiable An Advanced Settings section displayed: Enable Global Logout, indicating whether or not OIF should execute the SAML 2.0 Logout exchange with the partner as part of the logout process. HTTP POST SSO Response Binding: indicates how the OIF/SP will request the IdP to send the Assertion back to the SP. If checked, OIF/SP will request the IdP to send the Assertion using the HTTP-POST binding, otherwise will request the Artifact binding. HTTP Basic Authentication: if the Artifact binding is used, OIF/SP will need to connect to the IdP directly over SOAP to retrieve the SAML Assertion. Sometimes the IdP will enable HTTP Basic Authentication on the SOAP channel, and OIF/SP will need to provide username/password to the IdP (those credentials will be agreed between the IdP’s and SP’s administrators). Authentication Request NameID Format: indicates if OIF/SP should request via the SAML AuthnRequest a specific NameID to be used. If set to None, OIF/SP won’t request anything and the IdP will select the NameID format that was agreed upon out of band. If you set a value, be sure that it corresponds to what was agreed upon between the IdP’s and SP’s administrators. (Can be left blank) WLST To create a new SAML 2.0 IdP Partner without Metadata using the OIF WLST commands, execute the following steps (ensure first that you have all the data from the IdP partner, such as certificates, IdP identifiers and URLs): 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() Create SAML 2.0 IdP Partner without Metadata that will be called acmeIdP in OIF:addSAML20IdPFederationPartnerWithoutMetadata("acmeIdP", "https://acme.com/idp", "https://acme.com/saml20/sso", "https://acme.com/saml20/soap") By default, the new SP partner will be configured to: Use the default OAM Identity Store Use the user search base DN of the Identity Store (not overridden) Map the SAML Assertion using the NameID, matching the LDAP mail attribute Set the Authentication Request NameID Format to None Use HTTP-POST as the Default SSO Response Binding Use the default Identity Provider Attribute Profile No certificate has been uploaded for this IdP partner Exit the WLST environment:exit() Modifying Federation Settings via WLST In this section, I will list how to change the common SP Partner settings via the OIF WLST commands: SAML Assertion Mapping settings OAM Identity Store and User Search Base DN for SAML Assertion Mapping SAML 2.0 Logout SAML Signing Certificate SAML Encryption Certificate IdP Partner Attribute Profile for an IdP Partner SAML SSO Request and Response bindings I will assume that you are already in the WLST environment and connected using: 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() SAML Assertion Mapping settings To configure mapping settings for a SAML IdP Partner: Use the following command to map the Assertion via the NameID:setIdPPartnerMappingNameID(partnerName, userstoreAttr) partnerName is the name that was used to create the IdP Partner userstoreAttr: LDAP user attribute to match the NameID value. Use the following command to map the Assertion via a SAML Attribute:setIdPPartnerMappingAttribute(partnerName, assertionAttr, userstoreAttr) partnerName is the name that was used to create the IdP Partner assertionAttr: name of the SAML Attribute. userstoreAttr: LDAP user attribute to match the SAML Attribute value. Use the following command to map the Assertion via an LDAP query:setIdPPartnerMappingAttributeQuery(partnerName, attrQuery) partnerName is the name that was used to create the IdP Partner attrQuery: the LDAP query to be used (for example (&(givenname=%firstname%)(sn=%lastname%))). OAM Identity Store and User Search Base DN To configure OIF/SP to use a specific OAM Identity Store and/or a specific User Search Base DN when mapping the incoming SAML Assertion, execute the following command setPartnerIDStoreAndBaseDN(): Use the following command to set the OAM Identity Store only:setPartnerIDStoreAndBaseDN(partnerName, "idp", storeName="oid") partnerName is the name that was used to create the IdP Partner idp indicates the partner type storeName: references the OAM Identity Store to use Use the following command to set the Search Base DN only:setPartnerIDStoreAndBaseDN(partnerName, "idp", searchBaseDN="ou=managers,dc=acme,dc=com") partnerName is the name that was used to create the IdP Partner idp indicates the partner type searchBaseDN: indicates the search base DN to use Use the following command to set the OAM Identity Store and Search Base DN:setPartnerIDStoreAndBaseDN(partnerName, "idp", storeName="oid", searchBaseDN="ou=managers,dc=acme,dc=com") partnerName is the name that was used to create the IdP Partner idp indicates the partner type storeName: references the OAM Identity Store to use searchBaseDN: indicates the search base DN to use Use the following command to remove the OAM Identity Store and Search Base DN from the IdP partner entry: setPartnerIDStoreAndBaseDN(partnerName, "idp", delete="true") partnerName is the name that was used to create the IdP Partner idp indicates the partner type SAML 2.0 Logout To enable SAML 2.0 Logout and specify the IdP partner SAML 2.0 logout URLs, execute: The configureSAML20Logout() command:configureSAML20Logout("acmeIdP", "idp", "true", saml20LogoutRequestURL="https://acme.com/saml20/logoutReq", saml20LogoutResponseURL="https://acme.com/saml20/logoutResp") With acmeIdP being the name of partner created earlier idp indicates the partner type true indicates that SAML 2.0 Logout is enabled saml20LogoutRequestURL references the IdP partner endpoint that can process a SAML 2.0 LogoutRequest message saml20LogoutResponseURL references the IdP partner endpoint that can process a SAML 2.0 LogoutResponse message To disable the SAML 2.0 Logout for the IdP partner, execute: The configureSAML20Logout() command:configureSAML20Logout("acmeIdP", "idp", "false") With acmeIdP being the name of partner created earlier idp indicates the partner type false indicates that SAML 2.0 Logout is enabled SAML Certificates There are various WLST commands available to manage signing and encryption certificates: getFederationPartnerSigningCert() which prints the partner’s signing certificate in Base64 encoded format:getFederationPartnerSigningCert("acmeIdP", "idp") With acmeIdP being the name of partner created earlier idp indicates the partner type setFederationPartnerSigningCert() which uploads the signing certificate file passed as a parameter to the IdP Partner configuration:setFederationPartnerSigningCert("acmeIdP", "idp", "/tmp/cert.file") With acmeIdP being the name of partner created earlier idp indicates the partner type the third parameter indicates the location on the file system of the file containing the certificate: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding deleteFederationPartnerSigningCert() which removes the signing certificate from the IdP partner entry:deleteFederationPartnerSigningCert("acmeIdP", "idp") With acmeIdP being the name of partner created earlier idp indicates the partner type the getFederationPartnerEncryptionCert(),  setFederationPartnerEncryptionCert() and deleteFederationPartnerEncryptionCert() commands are similar to the above ones, except they will manage the partner’s encryption certificate: getFederationPartnerEncryptionCert("acmeIdP", "idp") setFederationPartnerEncryptionCert("acmeIdP", "idp", "/tmp/cert.file") deleteFederationPartnerEncryptionCert("acmeIdP", "idp") IdP Partner Attribute Profile To configure the IdP Partner Attribute Profile for a specific IdP Partner, use the following commands: To configure an IdP Partner to use a specific IdP Partner Attribute Profile, execute:setIdPPartnerAttributeProfile(partnerName, attrProfileID) partnerName is the name that was used to create the IdP Partner attrProfileID is the IdP Partner Attribute Profile ID To list the existing the IdP Partner Attribute Profiles, execute:listIdPPartnerAttributeProfileIDs() SAML SSO Request and Response bindings To configure the SAML bindings for a specific IdP Partner, use the following commands: To configure the IdP partner, execute:configureSAMLBinding(partnerName, partnerType, binding, ssoResponseBinding="httppost") partnerName is the name that was used to create the IdP Partner partnerType should be set to "idp" since the partner is an SP binding: the binding to use httppost for HTTP-POST binding, or httpredirect for HTTP-Redirect binding, for SAML 2.0 AuthnRequest and LogoutRequest/LogoutResponse messages. SAML 2.0 only ssoResponseBinding: The binding to use to send the SAML Assertion back to the IdP; httppost for HTTP-POST binding, or artifact for Artifact binding Examples The below commands could be used to add an IdP partner without SAML 2.0 Metadata: addSAML20IdPFederationPartnerWithoutMetadata("acmeIdP", "https://acme.com/idp", "https://acme.com/saml20/sso", "https://acme.com/saml20/soap")configureSAML20Logout("acmeIdP", "idp", "true", "https://acme.com/saml20/logoutReq", "https://acme.com/saml20/logoutResp")setFederationPartnerSigningCert("acmeIdP", "idp", "/tmp/acme-idp-cert.pem")setPartnerIDStoreAndBaseDN("acmeIdP", "idp", "oid")setIdPPartnerMappingNameID("acmeIdP", "mail") The below commands could be used to add an IdP partner with SAML 2.0 Metadata (in this example, I am using the default OAM Identity Styore): addSAML20IdPFederationPartner("acmeIdP", "/tmp/acme-idp-metadata-saml20.xml")setIdPPartnerMappingNameID("acmeIdP", "mail") In the next article, I will be covering SAML 1.1 and OpenID 2.0 IdP Partner creation.Cheers,Damien Carru

After having discussed in previous articles how to manage OIF/IdP, I will cover the administration of OIF/SP. In this post, I will explain how to set up a Federation agreement between OIF acting as a...

Example: Sending Attributes with OIF/ IdP

In this article, I will cover two examples on how to configure OIF/IdP to send attributes: Via the OAM Administration Console to send attributes to a SAML 2.0 SP Partner Via the OIF WLST commands to send attributes to an OpenID 2.0 RP Partner The sent attributes will be based on: The LDAP user record (attributes, DN…) The OAM user session (attributes, session count…) The browser’s HTTP request (cookie, user-agent…) Enjoy the reading! OAM Administration Console In this section, I will show how to configure OIF/IdP to send attributes via the admin console. The example will be based on a Federation with a remote SAML 2.0 SP partner, and the OIF/IdP will be configured to: Use the Unspecified NameID format Use the uid LDAP user attribute to set the NameID value Send the following attributes: Email address with the SAML attribute name set to Email An attribute containing a string beginning with “My name is “ and then both the first name and last name, separated by a space. The SAML attribute name will be set to Name UserID with attribute name set to UserID OAM Session count with the SAML attribute name set to SessionCount The client’s IP Address with the SAML attribute name set to IPAddress For this, I will create a new SP Attribute Profile, and assign it to acmeSP. Later on, if new SP partners are on boarded, it will be possible to assign the existing SP Attribute Profile so that OIF/IdP will send the same attributes to those new SPs. StepsTo create a new SP Attribute Profile, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the Service Provider Attribute Profiles tab Click on the “Create SP Attribute Profile” button Set up the basic information about the new SP Attribute Profile: Enter a name Enter a description if needed Note about “Default SP Partner Attribute Profile”: If checked, this will be the pre-assigned SP Attribute Profile when a new SP Partner is created via the UI If checked, it will be the SP Attribute Profile used for SP partners which do not have an SP Attribute Profile assigned (for example the ones created via WLST commands) We will now add the necessary attributes I listed earlier. Perform the following operations to add the Email attribute: Click the Add Entry button in the Attribute Mapping table Set up the email attribute: Message Attribute Name: Email Value: select user, then attr, then enter the LDAP Attribute containing the email address, mail in this case Always send: checked Perform the following operations to add the Name attribute: Click the Add Entry button in the Attribute Mapping table Set up the Name attribute: Message Attribute Name: Name Value: select expression, then enter the following string (in this example, the givenname LDAP attribute contains the first name, and sn the last name): My name is $user.attr.givenname $user.attr.sn Always send: checked Perform the following operations to add the UserID attribute: Click the Add Entry button in the Attribute Mapping table Set up the UserID attribute: Message Attribute Name: UserID Value: select user, then userid Always send: checked Perform the following operations to add the SessionCount attribute: Click the Add Entry button in the Attribute Mapping table Set up the SessionCount attribute: Message Attribute Name: SessionCount Value: select session, then count Always send: checked Perform the following operations to add the IPAddress attribute: Click the Add Entry button in the Attribute Mapping table Set up the IPAddress attribute: Message Attribute Name: IPAddress Value: select request, then client_ip Always send: checked The SP Attribute Profile has now been configured to send the required attributes to SP partners linked to this profile. The SP Partner will need to be updated to use the new SP Attribute Profile, as well as configured for the NameID settings mentioned earlier: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the Search Service Provider Partners Open the desired SP Partner Select Unspecified as the NameID format For NameID, select User ID Store Attribute then enter uid as the LDAP attribute containing the userID (note: one could have selected Expression in the drop down and entered an expression similarly to what was used earlier). In the Attribute Mapping section, select the newly created SP Attribute Profile  as the Attribute Profile Save Note about Always SendThe SP Attribute Profile is used for various protocols, including: SAML SSO, where the SP cannot request any attributes at runtime SAML SOAP Attribute exchange, where the SP can request any attributes at runtime OpenID 2.0, where the SP can request any attributes at runtime The “Always Send” option seen in the SP Attribute Profile section allows an administrator to instruct OIF/IdP to always send the attribute in an Assertion even if it was not requested by the SP partner. SAML AssertionBased on a user with the following characteristics, OIF/IdP will generate a SAML Assertion similar to the one shown below: UserID: alice First name: Alice Last name: Appleton Email: alice@idp.com SAML Assertion generated by OIF/IdP for alice:<samlp:Response ...>  <saml:Issuer ...>https://idp.com</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</saml:Issuer>    <dsig:Signature>     ...    </dsig:Signature>    <saml:Subject>      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">alice</saml:NameID>      ...    </saml:Subject>    <saml:Conditions NotBefore="2014-02-26T20:35:00Z" NotOnOrAfter="2014-02-26T22:35:00Z">      <saml:AudienceRestriction>        <saml:Audience>https://acme.com/sp</saml:Audience>      </saml:AudienceRestriction>    </saml:Conditions>    <saml:AuthnStatement AuthnInstant="2014-02-26T20:35:00Z" ...>      <saml:AuthnContext>        <saml:AuthnContextClassRef>urn:...:Password</saml:AuthnContextClassRef>      </saml:AuthnContext>    </saml:AuthnStatement>    <saml:AttributeStatement>      <saml:Attribute Name="Name" ...>        <saml:AttributeValue ...>My name is Alice Appleton</saml:AttributeValue>      </saml:Attribute>      <saml:Attribute Name="SessionCount" ...>        <saml:AttributeValue ...>1</saml:AttributeValue>      </saml:Attribute>      <saml:Attribute Name="Email" ...>        <saml:AttributeValue ...>alice@idp.com</saml:AttributeValue>      </saml:Attribute>      <saml:Attribute Name="IPAddress" ...>        <saml:AttributeValue ...>10.145.120.253</saml:AttributeValue>      </saml:Attribute>      <saml:Attribute Name="UserID" ...>        <saml:AttributeValue ...>alice</saml:AttributeValue>      </saml:Attribute>    </saml:AttributeStatement>  </saml:Assertion></samlp:Response>  WLST Commands In this section, I will show how to configure OIF/IdP to send attributes by using the OIF WLST commands. The example will be based on a Federation with a remote OpenID 2.0 SP partner, and the OIF/IdP will be configured to: Send the following attributes: Email address with the OpenID attribute name set to http://axschema.org/contact/email An attribute containing a string beginning with “My name is “ and then both the first name and last name, separated by a space. The OpenID attribute name will be set to http://openid.net/schema/namePerson/friendly UserID with the OpenID attribute name set to http://schemas.openid.net/ax/api/user_id OAM Session count with the OpenID attribute name set to http://session/count The client’s IP Address with attribute name set to http://session/ipaddress For this, I will create a new SP Attribute Profile, and assign it to acmeRP. Later on, if new RP partners are on boarded, it will be possible to assign the existing SP Attribute Profile so that OIF/IdP will send the same attributes to those new SPs. I will assume that you are already in the WLST environment and connected using: 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() Steps To configure the new SP Attribute Profile, execute the following steps: Create a new SP Attribute ProfilecreateSPPartnerAttributeProfile("openIDAttrProfile") Specify the name of the new SP Attribute Profile Create the Email attributesetSPPartnerAttributeProfileEntry("openIDAttrProfile", "http://axschema.org/contact/email", "$user.attr.mail") Specify the name of the SP Attribute Profile to modify Specify the OpenID attribute name to http://axschema.org/contact/email Set the value to the LDAP Attribute containing the email address, mail in this case: $user.attr.mail Create the Name attributesetSPPartnerAttributeProfileEntry("openIDAttrProfile", "http://openid.net/schema/namePerson/friendly", "My name is $user.attr.givenname $user.attr.sn") Specify the name of the SP Attribute Profile to modify Specify the OpenID attribute name to http://openid.net/schema/namePerson/friendly Set the value to (in this example, the givenname LDAP attribute contains the first name, and sn the last name): My name is $user.attr.givenname $user.attr.sn Create the UserID attributesetSPPartnerAttributeProfileEntry("openIDAttrProfile", "http://schemas.openid.net/ax/api/user_id", "$user.userid") Specify the name of the SP Attribute Profile to modify Specify the OpenID attribute name to http://schemas.openid.net/ax/api/user_id Set the value to the LDAP Attribute containing the email address, mail in this case: $user.attr.uid Create the OAM Session Count attributesetSPPartnerAttributeProfileEntry("openIDAttrProfile", "http://session/count", "$session.count") Specify the name of the SP Attribute Profile to modify Specify the OpenID attribute name to http://session/count Set the value to: $session.count Create the client’s IP Address attributesetSPPartnerAttributeProfileEntry("openIDAttrProfile", "http://session/ipaddress", "$request.client_ip") Specify the name of the SP Attribute Profile to modify Specify the OpenID attribute name to http://session/ipaddress Set the value to: $request.client_ip To update the SP partner to use that SP Attribute Profile, execute: The setSPPartnerAttributeProfile command:setSPPartnerAttributeProfile("acmeRP", "openIDAttrProfile") Specify the SP partner name Specify the name of the SP Attribute Profile to use OpenID Response Based on a user with the following characteristics, OIF/IdP will generate an OpenID Response similar to the one shown below: UserID: alice First name: Alice Last name: Appleton Email: alice@idp.com OpenID Response generated by OIF/IdP for alice: https://acme.com/sp/openidv20?refid=id-UnaYvk-mDQy6ZQB-4R39L4An4B0-&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=http%3A%2F%2Fadc00pcc.us.oracle.com%3A23002%2Foamfed%2Fidp%2Fopenidv20&openid.claimed_id=http%3A%2F%2Fadc00pcc.us.oracle.com%3A23002%2Foamfed%2Fidp%2Fopenidv20%3Fid%3Did-p4rWL%2FjzZAKwxAYLA%2FjOtP7s6fqjdyQ2BiSWZduaR5c%3D&openid.identity=http%3A%2F%2Fadc00pcc.us.oracle.com%3A23002%2Foamfed%2Fidp%2Fopenidv20%3Fid%3Did-p4rWL%2FjzZAKwxAYLA%2FjOtP7s6fqjdyQ2BiSWZduaR5c%3D&openid.return_to=http%3A%2F%2Fadc00peq.us.oracle.com%3A7499%2Ffed%2Fsp%2Fopenidv20%3Frefid%3Did-UnaYvk-mDQy6ZQB-4R39L4An4B0-&openid.response_nonce=2014-02-26T21%3A35%3A08Zid-uTAXy9lDK7TVvgezZVY3XZ06iSDcZb97zxiOl0qw&openid.assoc_handle=id-n-nN-qW2VAZa75-XJshWpmVHK53Yz0-lTZtrtsJm&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=2&openid.ax.type.attr1=http%3A%2F%2Fopenid.net%2Fschema%2FnamePerson%2Ffriendly&openid.ax.value.attr1=My+name+is+Alice+Appleton&openid.ax.type.attr2=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.value.attr2=alice&openid.ax.type.attr3=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.value.attr3=alice%40idp.com&openid.ax.type.attr4=http%3A%2F%2Fsession%2Fipaddress&openid.ax.value.attr4=10.145.120.253&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&openid.sig=TeDo%2FouX%2BXRI%2F1G8kJVsw5JOVY8%3D The decoded URL query parameters related to the attributes are: Name of attribute #0: openid.ax.type.attr0=http://session/count Value for attribute #0: openid.ax.value.attr0=2 Name of attribute #1: openid.ax.type.attr1= http://openid.net/schema/namePerson/friendly Value for attribute #1: openid.ax.value.attr1=My name is Alice Appleton Name of attribute #2: openid.ax.type.attr2= http://schemas.openid.net/ax/api/user_id Value for attribute #2: openid.ax.value.attr2=alice Name of attribute #3: openid.ax.type.attr3=http://axschema.org/contact/email Value for attribute #3: openid.ax.value.attr3=alice@idp.com Name of attribute #4: openid.ax.type.attr4=http://session/ipaddress Value for attribute #4: openid.ax.value.attr4=10.145.120.253 In my next article, I will be showing how to create IdP partners with OIF being a Service Provider.Cheers,Damien Carru

In this article, I will cover two examples on how to configure OIF/IdP to send attributes: Via the OAM Administration Console to send attributes to a SAML 2.0 SP Partner Via the OIF WLST commands to...

Sending Attributes with OIF/ IdP

In this article, I will cover how OIF can be easily configured to send attributes with the SSO Assertion to the partner during the Federation SSO operation. Those attributes can be set to data retrieved from: The LDAP user record (attributes, DN…) The OAM user session (attributes, session count…) The browser’s HTTP request (cookie, user-agent…) Note that configuring how SAML NameID values are set is similar to how attributes are configured in OIF. Enjoy the reading! Attributes in SSO Response During the Federation SSO operation, the IdP will issue a token targeted for the SP which will contain three kinds of data User information: data about the user that will also allow the SP to identify the user (userID, email address…) Federation authentication information: how the user was authenticated, when was the user challenged, when does the user’s session expire… Token related information used to validate the token’s issuance, to ensure that the IdP was the entity which created the token, that the token has not yet expired… The OIF/IdP server is able to send information as SAML / OpenID attributes to the SP/RP that can be based on: Static string User information: User ID Identity Store name User global unique identifier (guid) List of groups assigned to the user Value of an attribute stored in the LDAP user record OAM user’s session: Session’s authentication level Name of the Authentication Scheme used to challenge the client Number of opened sessions for the client Date in XML format when the session was created Date in XML format when the session will expire Value of an attribute stored in the OAM session. Note that this attribute might have been stored by another OAM component (for example OAM, OIF/SP…) Browser’s HTTP request: Value of specific HTTP Header Value of specific cookie Client’s IP address Combination of the above data as a single attribute: for example, the IdP could be configured to send the value of an attribute based on the UserID, Identity Store Name and the user’s session count. The above applies for sending attributes in SAML Assertions and OpenID SSO Responses, but it is also valid for setting the SAML NameID value in a SAML Assertion. Configuring OIF/IdP There are several ways to configure OIF/IdP for SAML NameID and SAML/OpenID attributes: Via the OAM Administration Console The SAML NameID can be configured by Indicating the LDAP user attribute to be used Setting an expression based on LDAP user record, session data, http request data or static data A SAML/OpenID attribute can be configured by indicating: The LDAP user attribute to be used One of the following user data: User ID Identity Store name User global unique identifier (guid) List of groups assigned to the user An OAM session attribute to be used One of the following session data: Session’s authentication level Name of the Authentication Scheme used to challenge the client Number of opened sessions for the client Date in XML format when the session was created Date in XML format when the session will expire An HTTP header to be used A cookie to be used The browser’s IP address A static string An expression based on LDAP user record, session data, http request data or static data Via a WLST command The SAML NameID can be configured by setting an expression based on LDAP user record, session data, http request data or static data A SAML/OpenID attribute can be configured by indicating an expression based on LDAP user record, session data, http request data or static data Expressions OIF/IdP is configured to send attributes/NameID via the use of an expression language similar to the one used in the OAM Authorization Policy Responses. Below is the list of possible elements that can be used to configure a NameID/Attribute. Type Data Expression Example User User ID $user.userid $user.userid Identity Store Name $user.id_domain $user.id_domain User GUID $user.guid $user.guid Comma separated list of groups which the user is member of $user.groups $user.groups LDAP User Attribute $user.attr.ATTR_NAME, with ATTR_NAME being the name of an LDAP User Attribute $user.attr.givenname OAM user’s session Authentication Level $session.authn_level $session.authn_level Authentication Scheme $session.authn_scheme $session.authn_scheme Session Count $session.count $session.count Session Creation Date $session.creation $session.creation Session Expiration Date $session.expiration $session.expiration Session Attribute $session.attr.ATTR_NAME, with ATTR_NAME being the name of an OAM Session Attribute $session.attr.fed.partner (this session attribute is set by OIF/SP when receiving an Assertion from a remote IdP and contains the IdP’s partner name; I will discuss more about those attributes in a future article)  Browser’s HTTP request HTTP Header value $request.httpheader.HTTP_HEADER_NAME, with HTTP_HEADER_NAME being the name of an HTTP Header $user.httpheader.user-agent Cookie value $request.cookie.COOKIE_NAME, with COOKIE_NAME being the name of a cookie $user.cookie.JSESSIONID Client’s IP Address $request.client_ip $request.client_ip Note about Always Send The SP Attribute Profile is used for various protocols, including: SAML SSO, where the SP cannot request any attributes at runtime SAML SOAP Attribute exchange, where the SP can request any attributes at runtime OpenID 2.0, where the SP can request any attributes at runtime The “Always Send” option seen in the SP Attribute Profile section allows an administrator to instruct OIF/IdP to always send the attribute in an Assertion even if it was not requested by the SP partner. In the next article, I will be showcasing two examples: How to configure OIF/IdP via the OAM Administration Console to send attributes to a SAML 2.0 SP Partner How to configure OIF/IdP via the OIF WLST commands to send attributes to an OpenID 2.0 RP Partner Cheers,Damien Carru

In this article, I will cover how OIF can be easily configured to send attributes with the SSO Assertion to the partner during the Federation SSO operation. Those attributes can be set to data...

Create SAML 1.1 / OpenID 2.0 SP Partners in OIF/ IdP

This article is a continuation of my previous entry where I discussed how to create SAML 2.0 SP Partners in OIF/IdP. In this article, I will cover how to set up a Federation agreement between OIF acting as an IdP and a remote SP Partner via the SAML 1.1 or OpenID 2.0 protocols: Set up a remote SAML 1.1 SP Partner Set up a remote OpenID 2.0 SP Partner The article will describe how to perform the above tasks either via the UI, or via the use of the OIF WLST commands. Establishing Federation Trust Establishing Trust between Federation partners is a pre-requisite before being able to perform any Federation SSO operation between the Federation servers. Trust establishment involves exchanging certificate information, if the protocol used relies on PKI X.509 certificates to secure message exchanges, as well as the locations/URLs of the services implementing the federation protocol. SAML 1.1 OAM Administration Console To create a new SAML 1.1 SP Partner, execute the following steps (ensure first that you have all the data from the SP partner, such as certificates, SP identifiers and URLs): Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the “Create Service Provider Partner” button In the Create screen: Enter a name for the partner Select SAML 1.1 as the Protocol Enter the Issuer / ProviderID of the SP Partner. In case the SP Partner does not have an Issuer (if the partner is only an SP, and not and IdP and SP), enter the Assertion Consumer Service URL Enter the Assertion Consumer Service URL for that SP Partner: this is the URL where the user will be redirected from OIF/IdP with the SAML Assertion. If the SP Partner will sign SAML messages, upload the Signing Certificate file: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding Enter how the NameID value will be set: If selecting User ID Store Attribute, this means that the NameID value will be set to the LDAP Attribute specified in the field next to the drop down If selecting Expression, this means that the NameID value will be set based on the expression specified in the field next to the drop down. See my next article on how to Configure IdP to send Attributes for more information on expressions. Select the Attribute Profile that will be used to populate the SAML Assertion with attributes. Click Save After the partner is created, the “Edit Partner” screen will be shown with: The settings set in the previous screen modifiable An Advanced Settings section displayed: SSO Response Binding: how the Assertion should be sent to the SP, if the SP did not request any particular binding Note: the “Attribute Query User Mapping” sub-section is only relevant to the SAML Attribute Authority/Request flow, when the SAML Attribute Query exchange is exercised. This flow is not part of the Federation SSO flow. WLST To create a new SAML 1.1 SP Partner using the OIF WLST commands, execute the following steps (ensure first that you have all the data from the SP partner, such as certificates, SP identifiers and URLs): 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() Create SAML 1.1 SP Partner that will be called acmeSP in OIF:addSAML11SPFederationPartner("acmeSP", "https://sp.com", "https://sp.com/saml11/sso") By default, the new SP partner will be configured to: Use Email Address as the NameID format User the mail LDAP user attribute as the NameID value Use HTTP-POST as the Default SSO Response Binding Use the default Service Provider Attribute Profile No certificate has been uploaded for this SP partner Exit the WLST environment:exit() Modifying Federation Settings via WLST In this section, I will list how to change the common SP Partner settings via the OIF WLST commands: SAML Signing Certificate SP Partner Attribute Profile for an SP Partner SAML NameID settings SAML SSO Request and Response bindings I will assume that you are already in the WLST environment and connected using: 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() SAML Signing Certificate There are various WLST commands available to manage signing and encryption certificates: getFederationPartnerSigningCert() which prints the partner’s signing certificate in Base64 encoded format:getFederationPartnerSigningCert("acmeSP", "sp") With acmeSP being the name of partner created earlier sp indicates the partner type setFederationPartnerSigningCert() which uploads the signing certificate file passed as a parameter to the SP Partner configuration:setFederationPartnerSigningCert("acmeSP", "sp", "/tmp/cert.file") With acmeSP being the name of partner created earlier sp indicates the partner type the third parameter indicates the location on the file system of the file containing the certificate: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding deleteFederationPartnerSigningCert() which removes the signing certificate from the SP partner entry:deleteFederationPartnerSigningCert("acmeSP", "sp") With acmeSP being the name of partner created earlier sp indicates the partner type SP Partner Attribute Profile To configure the SP Partner Attribute Profile for a specific SP Partner, use the following commands: To configure an SP Partner to use a specific SP Partner Attribute Profile, execute:setSPPartnerAttributeProfile(partnerName, attrProfileID) partnerName is the name that was used to create the SP Partner attrProfileID is the SP Partner Attribute Profile ID To list the existing the SP Partner Attribute Profiles, execute:listSPPartnerAttributeProfileIDs() SAML SSO Request and Response bindings To configure the SAML bindings for a specific SP Partner, use the following commands: To configure the SP partner, execute:configureSAMLBinding(partnerName, partnerType, binding, ssoResponseBinding="httppost") partnerName is the name that was used to create the SP Partner partnerType should be set to "sp" since the partner is an SP binding: this only applies to SAML 2.0. Use httppost ssoResponseBinding: The binding to use to send the SAML Assertion back to the SP; httppost for HTTP-POST binding, or artifact for Artifact binding SAML NameID Settings To configure NameID settings for a SAML SP Partner: Use the following command:setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false") partnerName is the name that was used to create the SP Partner nameIDFormat: possible values are orafed-emailaddress for urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress orafed-x509 for urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName orafed-windowsnamequalifier for urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName orafed-unspecified for urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified orafed-custom for a custom NameID format that will be specified in the customFormat parameter. customFormat containing the format to be used, if nameIDFormat was set to orafed-custom nameIDValueComputed: this setting is for SAML 2.0 only. Set it to false. OpenID 2.0 OAM Administration Console To create a new OpenID 2.0 SP/RP Partner, execute the following steps (ensure first that you have all the data from the SP partner, such as SP/RP realm and URLs): Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the “Create Service Provider Partner” button In the Create screen: Enter a name for the partner Select OpenID 2.0 as the Protocol Enter the realm of the RP/SP Partner. Enter the OpenID endpoint URL for that RP Partner: this is the URL where the user will be redirected from OIF/IdP with the OpenID Response. Select the Attribute Profile that will be used to populate the OpenID Response with attributes. Click Save After the partner is created, the “Edit Partner” screen will be shown with the same information displayed in the “Create Partner” screen. The OpenID 2.0 protocol mainly relies on user attributes being shared between the OP and the RP during the OpenID 2.0 SSO exchange. OIF/IdP achieves this via the SP Attribute Profile that will indicate which attributes will be added to the SSO response and how those attributes should be set. In my next article, I will be explaining how the IdP can be configured for sending attributes. WLST To create a new OpenID 2.0 RP Partner using the OIF WLST commands, execute the following steps (ensure first that you have all the data from the SP partner, such as SP/RP realm and URLs): 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() Create OpenID 2.0 RP Partner that will be called acmeRP in OIF:addOpenID20SPFederationPartner("acmeRP", "https://sp.com", "https://sp.com/sso/openid20") By default, the new SP partner will be configured to: Use the default Service Provider Attribute Profile Exit the WLST environment:exit() Modifying Federation Settings via WLST In this section, I will list how to change the common SP Partner settings via the OIF WLST commands: SP Partner Attribute Profile for an SP Partner I will assume that you are already in the WLST environment and connected using: 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() SP Partner Attribute Profile To configure the SP Partner Attribute Profile for a specific SP Partner, use the following commands: To configure an SP Partner to use a specific SP Partner Attribute Profile, execute:setSPPartnerAttributeProfile(partnerName, attrProfileID) partnerName is the name that was used to create the SP Partner attrProfileID is the SP Partner Attribute Profile ID To list the existing the SP Partner Attribute Profiles, execute:listSPPartnerAttributeProfileIDs() In the next article, I will be discussing how to configure OIF to populate the SSO response with attributes (LDAP user attributes, session attributes…).Cheers,Damien Carru

This article is a continuation of my previous entry where I discussed how to create SAML 2.0 SP Partners in OIF/IdP. In this article, I will cover how to set up a Federation agreement between OIF...

Creating SAML 2.0 SP Partners in OIF / IdP

In this article, I will discuss about the various kinds of information one has to know in order to be able to set up a Federation agreement between OIF acting as a SAML 2.0 IdP and a remote SAML 2.0 SP Partner, including: Set up a remote SAML 2.0 SP Partner with SAML 2.0 Metadata Set up a remote SAML 2.0 SP Partner without SAML 2.0 Metadata The article will describe how to perform the above tasks either via the UI, or via the use of the OIF WLST commands. Enjoy the reading! Establishing Federation Trust Establishing Trust between Federation partners is a pre-requisite before being able to perform any Federation SSO operation between the Federation servers. Trust establishment involves exchanging certificate information, if the protocol used relies on PKI X.509 certificates to secure message exchanges, as well as the locations/URLs of the services implementing the federation protocol. SAML 2.0 with Metadata OAM Administration Console To create a new SAML 2.0 SP Partner with Metadata, execute the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the “Create Service Provider Partner” button In the Create screen: Enter a name for the partner Select SAML 2.0 as the Protocol Click Load Metadata and upload the SAML 2.0 Metadata file for the SP Select the NameID format to set in the SAML 2.0 Assertion (for example Email Address NameID format) Enter how the NameID value will be set: If selecting User ID Store Attribute, this means that the NameID value will be set to the LDAP Attribute specified in the field next to the drop down If selecting Expression, this means that the NameID value will be set based on the expression specified in the field next to the drop down. See my next article on how to Configure IdP to send Attributes for more information on expressions. Select the Attribute Profile that will be used to populate the SAML Assertion with attributes. Click Save After the partner is created, the “Edit Partner” screen will be shown with: The settings set in the previous screen modifiable An Advanced Settings section displayed: Enable Global Logout, indicating whether or not OIF should execute the SAML 2.0 Logout exchange with the partner as part of the logout process. Encrypt Assertion: if the Assertion sent by the IdP should be encrypted using the SP’s encryption certificate (note: the SP must support encrypted assertions, and the SP’s encryption certificate must have been present in the SAML 2.0 SP Metadata) SSO Response Binding: how the Assertion should be sent to the SP, if the SP did not request any particular binding Note: the “Attribute Query User Mapping” sub-section is only relevant to the SAML Attribute Authority/Request flow, when the SAML Attribute Query exchange is exercised. This flow is not part of the Federation SSO flow. WLST To create a new SAML 2.0 SP Partner with Metadata using the OIF WLST commands, execute the following steps: 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() Create SAML 2.0 SP Partner with Metadata that will be called acmeSP in OIF:addSAML20SPFederationPartner("acmeSP", "/tmp/acme-sp-metadata-saml20.xml") By default, the new SP partner will be configured to: Use Email Address as the NameID format User the mail LDAP user attribute as the NameID value Not encrypt the Assertion Use HTTP-POST as the Default SSO Response Binding Exit the WLST environment:exit() SAML 2.0 without Metadata OAM Administration Console To create a new SAML 2.0 SP Partner without Metadata, execute the following steps (ensure first that you have all the data from the SP partner, such as certificates, SP identifiers and URLs): Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Identity Federation -> Identity Provider Administration Click on the “Create Service Provider Partner” button In the Create screen: Enter a name for the partner Select SAML 2.0 as the Protocol Select Enter Manually Enter the Issuer / ProviderID of the SP Partner Enter the Assertion Consumer Service URL for that SP Partner: this is the URL where the user will be redirected from OIF/IdP with the SAML Assertion. If the partner supports the SAML 2.0 Logout protocol: Enter the SAML 2.0 Logout Request URL where the partner can process a SAML 2.0 LogoutRequest message Enter the SAML 2.0 Logout Response URL where the partner can process a SAML 2.0 LogoutResponse message If the SP Partner will sign SAML messages, upload the Signing Certificate file: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding If the SAML Assertion will need to be encrypted and that the SP has an Encryption Certificate, upload the file: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding Enter how the NameID value will be set: If selecting User ID Store Attribute, this means that the NameID value will be set to the LDAP Attribute specified in the field next to the drop down If selecting Expression, this means that the NameID value will be set based on the expression specified in the field next to the drop down. See my next article on how to Configure IdP to send Attributes for more information on expressions. Select the Attribute Profile that will be used to populate the SAML Assertion with attributes. Click Save After the partner is created, the “Edit Partner” screen will be shown with: The settings set in the previous screen modifiable An Advanced Settings section displayed: Enable Global Logout, indicating whether or not OIF should execute the SAML 2.0 Logout exchange with the partner as part of the logout process. Encrypt Assertion: if the Assertion sent by the IdP should be encrypted using the SP’s encryption certificate (note: the SP must support encrypted assertions, and the SP’s encryption certificate must have been present in the SAML 2.0 SP Metadata) SSO Response Binding: how the Assertion should be sent to the SP, if the SP did not request any particular binding Note: the “Attribute Query User Mapping” sub-section is only relevant to the SAML Attribute Authority/Request flow, when the SAML Attribute Query exchange is exercised. This flow is not part of the Federation SSO flow. WLST To create a new SAML 2.0 SP Partner without Metadata using the OIF WLST commands, execute the following steps (ensure first that you have all the data from the SP partner, such as certificates, SP identifiers and URLs): 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() Create SAML 2.0 SP Partner without Metadata that will be called acmeSP in OIF:addSAML20SPFederationPartnerWithoutMetadata("acmeSP", "https://sp.com", "https://sp.com/saml20/sso") By default, the new SP partner will be configured to: Use Email Address as the NameID format User the mail LDAP user attribute as the NameID value Not encrypt the Assertion Not perform Logout Use HTTP-POST as the Default SSO Response Binding Use the default Service Provider Attribute Profile No certificate has been uploaded for this SP partner Exit the WLST environment:exit() Modifying Federation Settings via WLST In this section, I will list how to change the common SP Partner settings via the OIF WLST commands: SAML 2.0 Logout SAML Signing Certificate SAML Encryption Certificate SP Partner Attribute Profile for an SP Partner SAML NameID settings SAML SSO Request and Response bindings SAML 2.0 Encrypted Assertion I will assume that you are already in the WLST environment and connected using: 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() SAML 2.0 Logout To enable SAML 2.0 Logout and specify the SP partner SAML 2.0 logout URLs, execute: The configureSAML20Logout() command:configureSAML20Logout("acmeSP", "sp", "true", saml20LogoutRequestURL="https://sp.com/saml20/logoutReq", saml20LogoutResponseURL="https://sp.com/saml20/logoutResp") With acmeSP being the name of partner created earlier sp indicates the partner type true indicates that SAML 2.0 Logout is enabled saml20LogoutRequestURL references the SP partner endpoint that can process a SAML 2.0 LogoutRequest message saml20LogoutResponseURL references the SP partner endpoint that can process a SAML 2.0 LogoutResponse message To disable the SAML 2.0 Logout for the SP partner, execute: The configureSAML20Logout() command:configureSAML20Logout("acmeSP", "sp", "false") With acmeSP being the name of partner created earlier sp indicates the partner type false indicates that SAML 2.0 Logout is enabled SAML Certificates There are various WLST commands available to manage signing and encryption certificates: getFederationPartnerSigningCert() which prints the partner’s signing certificate in Base64 encoded format:getFederationPartnerSigningCert("acmeSP", "sp") With acmeSP being the name of partner created earlier sp indicates the partner type setFederationPartnerSigningCert() which uploads the signing certificate file passed as a parameter to the SP Partner configuration:setFederationPartnerSigningCert("acmeSP", "sp", "/tmp/cert.file") With acmeSP being the name of partner created earlier sp indicates the partner type the third parameter indicates the location on the file system of the file containing the certificate: either in PEM format (where the file contains as the first line -----BEGIN CERTIFICATE-----, then the certificate in Base64 encoded format, then the last line as -----END CERTIFICATE-----) or in DER format where the certificate is stored in binary encoding deleteFederationPartnerSigningCert() which removes the signing certificate from the SP partner entry:deleteFederationPartnerSigningCert("acmeSP", "sp") With acmeSP being the name of partner created earlier sp indicates the partner type the getFederationPartnerEncryptionCert(),  setFederationPartnerEncryptionCert() and deleteFederationPartnerEncryptionCert() commands are similar to the above ones, except they will manage the partner’s encryption certificate: getFederationPartnerEncryptionCert("acmeSP", "sp") setFederationPartnerEncryptionCert("acmeSP", "sp", "/tmp/cert.file") deleteFederationPartnerEncryptionCert("acmeSP", "sp") SP Partner Attribute Profile To configure the SP Partner Attribute Profile for a specific SP Partner, use the following commands: To configure an SP Partner to use a specific SP Partner Attribute Profile, execute:setSPPartnerAttributeProfile(partnerName, attrProfileID) partnerName is the name that was used to create the SP Partner attrProfileID is the SP Partner Attribute Profile ID To list the existing the SP Partner Attribute Profiles, execute:listSPPartnerAttributeProfileIDs() SAML SSO Request and Response bindings To configure the SAML bindings for a specific SP Partner, use the following commands: To configure the SP partner, execute:configureSAMLBinding(partnerName, partnerType, binding, ssoResponseBinding="httppost") partnerName is the name that was used to create the SP Partner partnerType should be set to "sp" since the partner is an SP binding: the binding to use httppost for HTTP-POST binding, or httpredirect for HTTP-Redirect binding, for SAML 2.0 AuthnRequest and LogoutRequest/LogoutResponse messages. SAML 2.0 only ssoResponseBinding: The binding to use to send the SAML Assertion back to the SP; httppost for HTTP-POST binding, or artifact for Artifact binding SAML NameID Settings To configure NameID settings for a SAML SP Partner: Use the following command:setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false") partnerName is the name that was used to create the SP Partner nameIDFormat: possible values are orafed-emailaddress for urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress orafed-x509 for urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName orafed-windowsnamequalifier for urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName orafed-kerberos for urn:oasis:names:tc:SAML:2.0:nameid-format:Kerberos orafed-transient for urn:oasis:names:tc:SAML:2.0:nameid-format:transient orafed-persistent for urn:oasis:names:tc:SAML:2.0:nameid-format:persistent orafed-unspecified for urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified orafed-custom for a custom NameID format that will be specified in the customFormat parameter. customFormat containing the format to be used, if nameIDFormat was set to orafed-custom nameIDValueComputed: true or false, and indicates whether or not to generate the NameID from a hash of the UserID, if the nameIDFormat is set to orafed-persistent (SAML 2.0 only) SAML 2.0 Encrypted Assertion To configure OIF/IdP to send or not encrypted SAML 2.0 assertions, execute the following commands: To configure OIF/IdP to encrypt the SAML 2.0 Assertion for an SP Partner, execute:updatePartnerProperty(partnerName, "sp", "sendencryptedassertion", "true", "boolean") partnerName is the name that was used to create the SP Partner To configure OIF/IdP to send a plain (default) the SAML 2.0 Assertion for an SP Partner, execute:updatePartnerProperty(partnerName, "sp", "sendencryptedassertion", "false", "boolean") partnerName is the name that was used to create the SP Partner Examples The below commands could be used to add an SP partner without SAML 2.0 Metadata: addSAML20SPFederationPartnerWithoutMetadata("acmeSP", "https://sp.com", "https://sp.com/saml20/sso")configureSAML20Logout("acmeSP", "sp", "true", saml20LogoutRequestURL="https://sp.com/saml20/logoutReq", saml20LogoutResponseURL="https://sp.com/saml20/logoutResp")setFederationPartnerSigningCert("acmeSP", "sp", "/tmp/cert.file")setFederationPartnerEncryptionCert("acmeSP", "sp", "/tmp/cert.file")setSPSAMLPartnerNameID("acmeSP", "orafed-emailaddress", nameIDValue="$user.attr.mail") The below commands could be used to add an SP partner with SAML 2.0 Metadata (in this example, I am using the default OAM Identity Styore): addSAML20SPFederationPartner("acmeSP", "/tmp/acme-sp-metadata-saml20.xml")setSPSAMLPartnerNameID("acmeSP", "orafed-emailaddress", nameIDValue="$user.attr.mail") In the next article, I will be covering SAML 1.1 and OpenID 2.0 SP Partner creation.Cheers,Damien Carru

In this article, I will discuss about the various kinds of information one has to know in order to be able to set up a Federation agreement between OIF acting as a SAML 2.0 IdP and a remote SAML 2.0...

Key and Certificate Management/Rollover in OIF/STS

Introduction As part of the Federation and WS-Trust protocol interaction, OIF/OSTS will need to use PKI Keys and Certificates for non repudiation and integrity via the use of digital signatures and confidentiality via digital encryption. In this article, I discuss about the Keys and Certificates management, including how to: Generate new keys and certificates Configure OIF and OSTS to use the new keys and certificates Implement a key rollover on a per partner basis Distribute the new certificates to partners In a Federation/WS-Trust exchange, the following occurs: OIF/OSTS will use its own PKI Keys and Certificates to perform signature and decryption operations on the SAML messages: Sign outgoing SAML messages and Assertions (XML Digital signatures or Query String signatures) Decrypt incoming SAML Assertions (XML Digital encryption) OIF/OSTS will use the partner’s signing or encryption certificate to: Verify signatures on incoming SAML messages and Assertions (XML Optionally encrypt outgoing SAML Assertions (XML Digital encryption) Example of SAML Messages with XML Digital Signatures: <samlp:Response ...>  <saml:Issuer>https://idp.com</saml:Issuer>  <samlp:Status>...</samlp:Status>  <saml:Assertion ...>    <saml:Issuer>https://idp.com</saml:Issuer>    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">      <ds:SignedInfo>        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>        <ds:Reference URI="#idhmf9KzAhxleuJ-L3vaVr979Ffa0">          <ds:Transforms>            <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>            <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>          </ds:Transforms>        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>          <ds:DigestValue>JGvBqil/NXa6dlMOn5ZhmBbOie8=</DigestValue>        </ds:Reference>      </ds:SignedInfo>      <ds:SignatureValue>VgOrU79ZJO4rzHiFTCDCGNmkb0...Y776QM4vEBBybIpbCCUih7I0aA==</ds:SignatureValue>    </ds:Signature>    <saml:Subject>      <saml:NameID>alice@acme.com</saml:NameID>      ...    </saml:Subject>    ...    </saml:Assertion></samlp:Response> Example of SAML Messages with query string signature (typically used by an SP to send the user to the IdP with an AuthnRequest): https://idp.com/saml20sso?SAMLRequest=hZJRT8IwFIX%2FStP3sW5BTW7YEhRREtQFplHeytZBQ9fW3i7Kv3cUTdAHfL09t985J3eEvFUWxp3f6oV47wR68tkqjRAeMto5DYajRNC8FQi%2BguX4YQ7pgIF1xpvKKEom%2FZ7U3EujM7r13iLEsaztoDItJVPjKhEQGW24QkHJbJJRWUfPuLtTFyuuS7bbsLVcpK92OmdN8XYb9SLETsw0eq59RlOWDCOWRikrkytIhsAuV5QU3x6upa6l3pw3vD6KEO7LsoiKp2VJyYtwGGz3ApqPDrEhgN1JEee%2F5YjCHbKHqC335%2BWHSZ%2B9CVIQ2ku%2Fp%2FlPaxhKG8UnRo6uLDz2i7NJYZSs9mSslPm4cYJ7kVHvOvE%2FPBkkf%2BCdRisq2UhR0zg%2FQn9fQ%2F4F&RelayState=id--mAK1whfUGrvoLqqhU2ysXLWSIw-&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=S5TZ0uwK9SMZUgBfDaipbNhlLqbbSG9t4rgA9n3%2FwxFsK7H66IoK6G%2BDfaIUvc5bLtTrwmxsa2iB2gjFx8p5Q6%2FgH8OtFbT7mKZ7z8FihgxxTKjHJ2FQocOEn%2FrkcRKAAq%2Blig5xVSlR%2BzLq1vkQzIMNOrfLw%2FM6uk3i%2Fk54EnQ%3D SAMLRequest: SAML AuthnRequest messageRelayState: SAML 2.0 Relay State parameterSigAlg: signature algorithmSignature: signature bytes covering SAMLRequest, RelayState and SigAlg parameters The OIF/OSTS PKI keys and certificates are stored in the $DOMAIN_HOME/config/fmwconfig/.oamkeystore Java Keystore file (note: this keystore is of type JCEKS, not JKS), and the OIF/OSTS settings reference the key entries from the .oamkeystore, so that they can be used by the components for SAML operations. Install During the installation phase of OAM, a key pair and self signed certificate will be generated and OIF/OSTS will be configured to use it for signing and decryption operations The OAM installer creates the .oamkeystore with a random password (see the “Setting new key entries” section on how to reset that password) A new key entry called stsprivatekeyalias is created RSA Key Pair Self signed certificate Subject and Issuer set to: “cn=<MACHINE_HOSTNAME>” Two entries are created in the OIF/OSTS configuration: osts_signing referencing the stsprivatekeyalias Key Entry in the .oamkeystore osts_encryption referencing the stsprivatekeyalias Key Entry in the .oamkeystore OIF is set up to use osts_signing entry for signature operations and osts_encryption for decryption operations OSTS is set up to use osts_encryption for decryption operations, and osts_signing for signature operations in the SAML Issuance Templates Setting new key entries The process of creating new PKI Keys and Certificates before using them in OIF/OSTS is two-fold: Creating the key entry in the .oamkeystore Creating the entry in OIF/OSTS to reference the key entry in .oamkeystore Note: the keys and certificates need to be stored in the .oamkeystore; HSM are not supported. Creating a new Key Entry in the .oamkeystore As mentioned previously, the password of the .oamkeystore Keystore is unknown to the administrator, and it will need to be reset in order to make modifications. This operation is done via a WLST command: 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() Reset the .oamkeystore password:resetKeystorePassword() Exit the WLST environment:exit() One way to create a new key entry in the .oamkeystore is to use the JDK’s KeyTool application. In this example, two key entries with self signed certificates will be created, one with the alias samlsigning and the other with the alias samlencryption (replace $JDK_HOME and $DOMAIN_HOME by the correct path; for the keystore password enter the one you selected during the reset operation): $JDK_HOME/bin/keytool -genkeypair -alias samlsigning -keyalg RSA -keysize 2048 -sigalg sha1withrsa -dname cn="ACME SAML Signing" -validity 1000 -keystore $DOMAIN_HOME/config/fmwconfig/.oamkeystore -storetype JCEKS $JDK_HOME/bin/keytool -genkeypair -alias samlencryption -keyalg RSA -keysize 2048 -sigalg sha1withrsa -dname cn="ACME SAML Encryption" -validity 1000 -keystore $DOMAIN_HOME/config/fmwconfig/.oamkeystore -storetype JCEKS Updating OIF/OSTS settings Once the key entries have been created in the .oamkeystore, new SAML key entries must be created in OIF/OSTS before those keys can be used during SAML protocol exchanges. To create a new SAML key entry in OIF/OSTS: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Federation Settings or Security Token Service Settings Create a new entry: In the Keystore section, click the “+” button Enter a KeyID for the new entry (for example saml-signing) Select the alias for the new key entry from the dropdown which lists the key entries in the .oamkeystore (for example samlsigning) Enter the password for the key entry that you set when creating that key in the previous section Repeat the process for other entries if needed Apply Note: different key IDs can reference the same key entry in the OAM Keystore Using new key entries Global Settings To update the global OIF settings to use new keys and certificates to sign and decrypt SAML messages, perform the following operations: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Federation Settings Select the Signing Key from the dropdown list of key entries (these entries are defined in the Keystore section). For example select saml-signing Select the Encryption Key from the dropdown list of key entries (these entries are defined in the Keystore section). For example select saml-encryption Apply (Note: after applying, you might need to redistribute certificates and/or SAML 2.0 Metadata to partners) To update the global OSTS settings to use new keys and certificates to decrypt SAML messages, perform the following operations: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Security Token Service Settings Select the Default Encryption Template from the dropdown list of key entries (these entries are defined in the Keystore section). For example select saml-encryption Apply (Note: after applying, you might need to redistribute certificates to partners) To update the OSTS settings to use new keys and certificates to sign SAML messages, perform the following operations: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Security Token Service -> Token Issuance Templates Click on the SAML Issuance Template you want to update Click on the Security tab Select the Signing Keystore Access Template Id from the dropdown list of key entries (these entries are defined in the Keystore section). For example select saml-signing Apply (Note: after applying, you might need to redistribute certificates to partners) Key Rollover per Partner When an OIF/OSTS deployment is involved with numerous partners, it might be difficult to change the global signing/encryption keys/certificates at once, since this would require notifying all the partners at the same time of the changes, and having them update their configuration with the new certificates/SAML 2.0 metadata. Note: after updating the keys/certificates in OIF/OSTS, the Federation/WS-Trust flows will not work with the partners until they upload the new certificates in their system. OIF/OSTS provides an easy way to perform a key rollover on a per partner basis, thus allowing the OAM administrator to plan how and when to notify specific partners of the key and certificates change. Performing key rollover for OIF IdP or SP partners involve: Setting up new keys and certificates as explained in the previous section Updating the IdP or SP partner configuration in OIF to use the new keys and certificates Notifying the partner with New SAML 2.0 Metadata specifically generated with those new keys/certificates Or new certificates corresponding to the new key entries Performing key rollover for OSTS Relying Party partners involve: Setting up new keys and certificates as explained in the previous section If not already one: Creating a new Relying Party Profile, which would be a copy of the current Relying Party Profile used by the Relying Party partner Creating a new SAML Issuance Template, copy of the SAML Issuance Template referenced by the currently Relying Party Profile used by the Relying Party partner Update the new Relying Party Profile to use the new SAML Issuance Template instead of the current one Update the new SAML Issuance Template to use the new keys/certificates Assign the Relying Party partner to the new Relying Party Profile Note: OIF key rollover can be done via a group of partners by using Partner Profiles in the OIF configuration. I will discuss in a future article Partner Profiles in OIF and will include a section about key rollover using Partner Profiles. OIF Key Rollover When performing a key rollover for a specific partner, you will first need to update the IdP or SP Partner configuration in OIF via a WLST command: 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() Update the partner configuration to set the Signing Key property (referenced by signingkeystoreaccesstemplateid) to the key entry ID defined in the Federation Settings -> Keystore section (in this example, saml-signing is the key entry ID; replace  <PARTNER_NAME> by the name of the partner in OIF; replace <IDP_OR_SP> by IDP or SP, the type of partner):updatePartnerProperty("<PARTNER_NAME>", "<IDP_OR_SP>", "signingkeystoreaccesstemplateid", "saml-signing", "string") Update the partner configuration to set the Encryption Key property (referenced by encryptionkeystoreaccesstemplateid) to the key entry ID defined in the Federation Settings -> Keystore section (in this example, saml-encryption is the key entry ID; replace  <PARTNER_NAME> by the name of the partner in OIF; replace <IDP_OR_SP> by IDP or SP, the type of partner):updatePartnerProperty("<PARTNER_NAME>", "<IDP_OR_SP>", "encryptionkeystoreaccesstemplateid", "saml-encryption", "string") Exit the WLST environment:exit() Once the partner configuration has been updated, the partner needs to use the SAML 2.0 metadata or certificate information. To generate this information: If you need to provide SAML 2.0 metadata for the new signing and encryption key, open a browser and use the following URL to generate the metadatahttp://oam-runtime-host:oam-runtime-port/oamfed/idp/metadata?signid=<SIGN_KEYENTRY_ID>&encid=<ENC_KEYENTRY_ID> The signid query parameter contains the key entry ID for the signing certificate. Replace <SIGN_KEYENTRY_ID> The encid query parameter contains the key entry ID for the encryption certificate. Replace <SIGN_KEYENTRY_ID> An example would be:http://oam.com/oamfed/idp/metadata?signid=saml-signing&encid=saml-encryption If you need to provide the certificate file for the new key, open a browser and use the following URL to generate the certificate in PEM format:http://oam-runtime-host:oam-runtime-port/oamfed/idp/cert?id=<KEYENTRY_ID> The id query parameter contains the key entry ID for the certificate. Replace <KEYENTRY_ID> An example would be:http://oam.com/oamfed/idp/cert?id=saml-signing Note: you can first generate the SAML 2.0 Metadata/Certificate and provide it to the partner before updating the partner configuration. OSTS Key Rollover To explain OSTS key rollover, we will take an example of: Three Relying Party partners: RP1, RP2 and RP3 Two Relying Party Profiles: RPprofileA and RPprofileB, with RP1 and RP2 using RPprofileA and RP3 using RPprofileB Two SAML 2.0 Issuance Templates, SAMLIssuanceA referenced by RPprofileA and SAMLIssuanceB referenced by RPprofileB The rollover will consist of switching the RP1 first, then RP2, then RP3, to have those partners use the new saml-signing certificate. To switch RP1, the following operations will need to be performed: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Security Token Service -> Partner Profiles -> Relying Party Profiles Create a new Relying Party Profile called NewRPprofileA, copy of RPprofileA Navigate to Security Token Service -> Token Issuance Templates Create a new SAML Issuance Template called NewSAMLIssuanceA, copy of SAMLIssuanceA Update NewRPprofileA to reference NewSAMLIssuanceA SAML 2.0 Issuance Template Update NewSAMLIssuanceA SAML 2.0 Issuance Template in the Security tab to use the new key entry Navigate to Security Token Service -> Partners -> Relying Parties Open RP1 and configure it to use the NewRPprofileA Relying Party Profile: from then on, OSTS will use the new key entry saml-signing to sign outgoing SAML 2.0 Assertions for the RP1 Relying Party partner Download the new certificates from OSTS by opening a browser and use the following URL to generate the certificate in PEM format:http://oam-runtime-host:oam-runtime-port/sts/servlet/samlcert?id=<KEYENTRY_ID> The id query parameter contains the key entry ID for the certificate. Replace <KEYENTRY_ID> An example would be:http://oam.com/sts/servlet/samlcert?id=saml-signing Provide the certificate to the partner Switching RP2 to the new certificate will be faster, since the new Relying Party profile and SAML Issuance Template have already been created. To switch RP2, the following operations will need to be performed: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Security Token Service -> Partners -> Relying Parties Open RP1 and configure it to use the NewRPprofileA Relying Party Profile: from then on, OSTS will use the new key entry saml-signing to sign outgoing SAML 2.0 Assertions for the RP1 Relying Party partner Provide the certificate to the partner Switching RP3 to the new certificate will consist of repeating the operations executed for RP1, since the new Relying Party profile and SAML Issuance Template for RP3 have not been created yet. Note: you can first provide the new certificate to the partner before updating the OSTS configuration. In the next article I will be discussing about IdP administration and how to create SP partners.Cheers,Damien Carru

Introduction As part of the Federation and WS-Trust protocol interaction, OIF/OSTS will need to use PKI Keys and Certificates for non repudiation and integrity via the use of digital signatures and...

OIF/OSTS Service Information

OIF and OSTS are two products designed to provide Federation capabilities across security domains: Cross domain SSO for browser based Web SSO flows Cross domain Web Services Security (WSS) for SOAP clients and servers via the WS-Trust protocol Federation between services is based on trust which is established by exchanging X.509 certificates used for sign/verify and encrypt/decrypt the Federation messages Locations of the Federation services SAML 2.0 Metadata if supported by the partners, when SAML 2.0 Federation SSO is used In this article, I will discuss about the various kinds of information one has to know in order to be able to set up a Federation agreement between OIF and remote partners, including: How to enable OIF/OSTS services SAML/OpenID Identifiers for OIF/OSTS SAML 2.0 Metadata Certificates Service endpoints Enabling OIF / OSTS Services OIF/OSTS Enablement Out of the box, the OIF and OSTS components are disabled in the OAM server, and need to be enabled prior to using them. To enable OIF and/or OSTS, you will need to: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Available Services Enable the components you need To verify that OIF is correctly enabled, you can attempt to download OIF SAML 2.0 Metadata from http(s)://oam-runtime-host:oam-runtime-port/oamfed/idp/metadata OIF Services After having turned on the OIF component, all OIF services are enabled: IdP SP SAML Attribute Authority SAML Attribute Requester To selectively enable or disable those above services, use the OIF WLST command configureFederationService(): 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 configureFederationService() command:configureFederationService(<SERVICE>, <true/false>) Replace <SERVICE> by idp, sp, attributeresponder or attributerequester Set true to enable the service or false to disable it For example, to disable the SAML Attribute Authority service, execute:configureFederationService("attributeresponder", "false") SAML Issuer / OpenID Realm When communicating via the SAML protocols, Federation servers identify themselves via the Issuer element in the SAML messages. This is also known as the Entity ID or the Provider ID. This identifier must be unique among partners so that one identifier references a single entity. In the OpenID 2.0 protocol, the Relying Party or Service Provider can be identified via the Realm element. OIF During installation, the Provider ID used in SAML operations and the Realm used in OpenID 2.0 exchanges are set to: SAML Provider ID:http://oam-runtime-hostname:oam-runtime-port/oam/fed OpenID 2.0 Realm:http://oam-runtime-hostname:oam-runtime-port To change the Provider ID, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Federation Settings Set the Provider ID to the desired value Note #1: the Succinct ID which is the SHA-1 hash of the Provider ID and used in SAML Artifact protocol will be re-generated Note #2: after resetting the Provider ID, you will need to notify all the existing partners of the change and redistribute SAML 2.0 Metadata if necessary Apply OSTS During installation, the Provider ID used in SAML Issuance Templates is set to:http://oam-runtime-hostname:oam-runtime-port/oam/fed To change or retrieve the Provider ID from an Issuance Template, perform the following steps: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Security Token Service Settings -> Token Issuance Templates Click on the desired SAML Issuance Template Click on the Issuance Properties tab The Provider ID is the Assertion Issuer property. Set the corresponding field to update the Provider ID for this SAML Issuance Template Apply SAML 2.0 Metadata The SAML 2.0 SSO protocol define the Metadata XML document which is used by Federation servers to publish all information the partners will need to be aware of in order to exchange SAML 2.0 messages. The SAML 2.0 Metadata of a Federation server includes: The X.509 signing certificate to allow the remote partner to verify messages signed by the Federation server The X.509 encryption certificate to allow the remote partner to encrypt messages that only the Federation server will be able to decrypt Roles supported by the Federation server: IdP SP SAML Attribute Authority SAML Attribute Requester … Services for each of those roles SSO, Logout Type of SAML binding used to communicate with those services (HTTP-Redirect, HTTP-POST, Artifact, SOAP…) Location indicating the endpoint where a service is published ResponseLocation indicating the endpoint were a service is published for response messages The OIF Metadata can be retrieved from the OAM Administration Console: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Federation Settings Click on the Export Metadata button Save the file on your local computer The OIF Metadata can also be retrieved by accessing a URL on the OAM/OIF runtime server:http://oam-runtime-host:oam-runtime-port/oamfed/idp/metadata Note: it is possible to generate OIF Metadata for specific signing and encryption keys by using the following URL (read my next article about Key Management in OIF/OSTS for more information)http://oam-runtime-host:oam-runtime-port/oamfed/idp/metadata?signid=<SIGN_KEYENTRY_ID>&encid=<ENC_KEYENTRY_ID> The signid query parameter contains the key entry ID for the signing certificate. Replace <SIGN_KEYENTRY_ID> The encid query parameter contains the key entry ID for the encryption certificate. Replace <SIGN_KEYENTRY_ID> An example would be:http://oam.com/oamfed/idp/metadata?signid=osts_signing&encid=osts_encryption Certificates For SAML 2.0 partners not supporting the consumption of SAML 2.0 Metadata, or for SAML 1.1 partner or even STS partners, the administrator will need to provide the signing certificate and possibly the encryption certificate as standalone files. The OIF/OSTS Settings section in the administration console lists the key entries used by the system (read my next article about Key Management in OIF/OSTS for more information) To view the current key entries known to OIF/OSTS: Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole Navigate to Configuration -> Federation Settings / Security Token Service Settings In the Keystore section, see the list of Key IDs, each representing a key entry in OIF/OSTS, and each referencing a key entry in the OAM Keystore (different key IDs can reference the same key entry in the OAM Keystore) To retrieve the certificate file of a specific key ID, open a browser and use the following URL to generate the certificate in PEM format: For OIF:http://oam-runtime-host:oam-runtime-port/oamfed/idp/cert?id=<KEYENTRY_ID> The id query parameter contains the key entry ID for the certificate. Replace <KEYENTRY_ID> An example would be:http://oam.com/oamfed/idp/cert?id=saml-signing    For OSTS:http://oam-runtime-host:oam-runtime-port/sts/servlet/samlcert?id=<KEYENTRY_ID> The id query parameter contains the key entry ID for the certificate. Replace <KEYENTRY_ID> An example would be:http://oam.com/sts/servlet/samlcert?id=saml-signing OIF Endpoints This section will list the various endpoints published by OIF, some specific to a protocol, others protocol agnostic. Note: it is important to access the OIF services via the public endpoints (load balancer, HTTP reverse proxy…) in order for HTTP cookies set in the browser to be sent back by the browser. In this list, only paths will be listed, not the public protocol/hostname/port. SAML 2.0 The IdP SAML 2.0 endpoints are: SSO Service to receive AuthnRequest messages HTTP-Redirect binding: /oamfed/idp/samlv20 HTTP-POST binding: /oamfed/idp/samlv20 SOAP binding for ECP clients: /oamfed/idp/soap Artifact Service for SP to send SOAP ArtifactResolve messages during SSO Artifact: /oamfed/idp/soap Logout Service to receive LogoutRequest and LogoutResponse messages LogoutRequest: HTTP-Redirect binding: /oamfed/idp/samlv20 HTTP-POST binding: /oamfed/idp/samlv20 LogoutResponse HTTP-Redirect binding: /oamfed/idp/samlv20 HTTP-POST binding: /oamfed/idp/samlv20 The SP SAML 2.0 endpoints are: Assertion Consumer Service to receive SAML Assertions HTTP-POST binding: /oam/server/fed/sp/sso Artifact binding: /oam/server/fed/sp/sso Logout Service to receive LogoutRequest and LogoutResponse messages LogoutRequest: HTTP-Redirect binding: /oamfed/sp/samlv20 HTTP-POST binding: /oamfed/sp/samlv20 LogoutResponse HTTP-Redirect binding: /oamfed/sp/samlv20 HTTP-POST binding: /oamfed/sp/samlv20 The SAML 2.0 Attribute Authority/Responder endpoints are: SOAP Service for SAML Attribute Requester to send SOAP Attribute Query messages: /oamfed/aa/soap The SAML 2.0 Attribute Requester does not publish any endpoint. SAML 1.1 The IdP SAML 1.1 endpoints are: SSO Service to start SAML 1.1 Federation SSO URL: /oamfed/idp/samlv11sso Query parameters (URL encode properly the query parameter values) providerid: indicates the SP partner name or SP Provider ID with which to start Federation SSO TARGET: indicates the value to send as the TARGET to the SP. Typically, this will contain the URL where the user should be redirected after the Federation SSO operation Artifact Service for SP to send SOAP ArtifactResolve messages during SSO Artifact: /oamfed/idp/soapv11 The SP SAML 1.1 endpoints are: Assertion Consumer Service to receive SAML Assertions URL: /oam/server/fed/sp/sso The SAML 1.1 Attribute Authority/Responder endpoints are: SOAP Service for SAML Attribute Requester to send SOAP Attribute Query messages: /oamfed/aa/soapv11 The SAML 1.1 Attribute Requester does not publish any endpoint. OpenID 2.0 The IdP OpenID 2.0 endpoints are: SSO Service to receive OpenID Authn Request messages from RPs URL: /oamfed/idp/openidv20 Discovery Service where XRDS is published: URL: /oamfed/idp/openidv20 The SP OpenID 2.0 endpoints are: SSO Service to receive OpenID Authn Response messages from OPs URL: /oam/server/fed/sp/sso RP Realm: see SAML Issuer / OpenID Realm section about that identifier Other Services There are a few services that are protocol agnostic: IdP initiated SSO Service URL: /oamfed/idp/initiatesso Query parameters (URL encode properly the query parameter values) providerid: indicates the SP partner name or SP Provider ID with which to start Federation SSO returnurl: indicates where the user should be redirected after the Federation SSO operation SP initiated SSO URL: /oamfed/sp/initiatesso Query parameters (URL encode properly the query parameter values) providerid: indicates the IdP partner name or IdP Provider ID with which to start Federation SSO returnurl: indicates where the user should be redirected after the Federation SSO operation Test SP which allows you to test OIF/SP with a remote IdP partner URL: /oamfed/user/testspsso Note: prior to using this service, you must enable it via the configureTestSPEngine() command: 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 configureTestSPEngine () command:configureTestSPEngine(<true/false>) Set true to enable the service or false to disable it For example, to enable the Test SP service, execute:configureTestSPEngine("true") OSTS Endpoints OSTS publishes SOAP endpoints based on how the Security Token Service is configured. The Security Token Service -> Endpoints section in the OAM Administration Console lists the endpoints defined for OSTS and how they are protected by the OWSM Agent For a given endpoint (for example /wss11user), the following URLs are published: Over SOAP 1.2: /sts/wss11user WSDL for operations over SOAP 1.2: /sts/wss11user?wsdl Over SOAP 1.1: /sts/wss11user/soap11 WSDL for operations over SOAP 1.1: /sts/wss11user/soap11?wsdl In the next article, I will discuss about PKI Key and Certificate management in OIF/OSTSCheers,Damien Carru

OIF and OSTS are two products designed to provide Federation capabilities across security domains: Cross domain SSO for browser based Web SSO flows Cross domain Web Services Security (WSS) for SOAP...

Oracle Identity Federation 11.1.2.2.0 has been released!

Oracle Identity Federation (OIF) has been released as part of Oracle Fusion Middleware 11gR2 Release 2 (11.1.2.2.0)! This new version of OIF provides Identity Provider (IdP) and Service Provider (SP), a.k.a. Relying Party (RP), support for the SAML 2.0, SAML 1.1 and OpenID 2.0 protocols. The admin interfaces have been revamped to provide a comprehensive and easy way for administrators to manage Federation partnership on a day-to-day basis: while the UI allows the basic administration of Federation settings, which would cover most of the daily use cases, the OIF WLST command scripting tools allow advanced configuration of the Federation servers and its partners.In this article, I will discuss about the features included in OIF 11.1.2.2.0: Native Integration with OAM Protocols Additional Features Native Integration with OAM OIF 11.1.2.2.0 is now part of Oracle Access Manager (OAM) and is natively integrated with the server's SSO features. This allows the different OIF component's to tightly interact with OAM's components: IdP module responsible to authenticate users on behalf of remote Service Providers: Integrates with OAM SSO server for user authentication Leverages the various OAM Authentication Schemes to challenge users Bundled in the OIF J2EE Web Application in the OAM J2EE Application Integrates with the OAM Token Issuance Policy when creating SAML/User Assertions SP module responsible to delegate authentication of a user to a remote Identity Provider: Bundled as a collection of OAM Authentication Plugins in an OAM Authentication Module Available as an OAM Authentication Scheme: a non-authenticated user requesting access to a resource protected by an OAM Federation Scheme will result in a Federation SSO operation being triggered with a remote IdP Able to save attributes present in the SAML/OpenID Assertions into the OAM session The following diagram depicts the internal architecture of OIF 11.1.2.2.0: ProtocolsThe protocols supported by the Federation server include: SAML 2.0 SSO/IdP HTTP-Redirect, HTTP-POST, PAOS bindings when receiving an AuthnRequest message Artifact, HTTP-POST bindings when sending an SSO Response with Assertion SSO/SP: HTTP-Redirect, HTTP-POST bindings when sending an AuthnRequest message Artifact, HTTP-POST bindings when receiving an SSO Response with Assertion Logout IdP/SP:  HTTP-Redirect, HTTP-POST bindings Attribute Authority Attribute Request Identity Provider Discovery SAML 1.1 SSO/IdP: Artifact, HTTP-POST bindings when sending an SSO Response with Assertion SSO/SP: Artifact, HTTP-POST bindings when receiving an SSO Response with Assertion Attribute Authority Attribute Request OpenID 2.0 IdP/SP Authentication 2.0 Attribute Exchange 1.0 Provider Authentication Policy Extension 1.0 Simple Registration Extension 1.0 Additional Features On top of supporting the above list of SAML and OpenID protocols, OIF provides other features aimed at facilitating the use of Federation SSO for most scenarios: Identity Provider Discovery: When a Federation SSO operation is triggered, if the IdP is not determined yet, OIF/SP is capable of interacting with an IdP Discovery Service whose task will be to select the IdP to be used. The IdP Discovery Service is typically a standalone service implemented and managed by an integrator that will determine the IdP to be used at runtime. The determination could be implemented based on the user's location, one some cookies saved in the user's browser... OIF 11.1.2.2.0 provides a basic IdP Discovery Service listing to the users the list of registered IdP partners and inviting the user to select the one to use for the Federation SSO operation Authorization during IdP SSO: When OIF/IdP performs a Federation SSO operation on behalf of a remote SP, it can evaluate if the user is allowed to perform a Federation SSO with that SP Partner The authorization is based on Token Issuance Policies, with: The resource being the SP partner The constraint being always true, of based on the user's identity/group Expression language for SAML Token Issuance: During the SAML Assertion creation, the OIF/IdP can include SAML Attributes with values based on LDAP User record OAM Session data User's browser information The administrator uses an expression to set SAML Attribute values similar to the one used for OAM Policy Responses SAML Attributes available as OAM Session attributes When OIF acts as an SP, the attributes from the SAML/OpenID Assertion will be stored in the OAM User Session Those attributes will then be available for Policy constraints Policy Responses to be injected in the HTTP request for web applications protected by a WebGate agent User Authentication: OIF/IdP integrates with OAM to authenticate users via the available Authentication Schemes OIF/IdP can use a specific default Authentication Scheme on a per SP Partner basis In the next article, I will be discussing about the basic use of OIF (enabling OIF, retrieving SAML 2.0 metadata, services location...)

Oracle Identity Federation (OIF) has been released as part of Oracle Fusion Middleware 11gR2 Release 2 (11.1.2.2.0)! This new version of OIF provides Identity Provider (IdP) and Service Provider (SP),...