Adding Oracle Identity Federation to an Existing Fusion Applications Deployment Part 2

Introduction

This is the second part of a two-part article. Click here to view Part 1.

This guide is meant for existing FA customers who have deployed FA without OIF and who now wish to add this security component to the deployment to provide federated SSO to FA. Customers who have not yet begun their deployment can and should follow the Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) for the FA Release that they are deploying. The content of this article was generated using an FA Release 5 (11.1.5) environment, and it applies to FA versions 11.1.3 through 11.1.6. For those who are performing this on FA version 11.1.3 or 11.1.4, the EDG for FA version 11.1.5 should be referenced for additional information on the OIF deployment.

This article assumes that the implementer is conversant with OIF version 11.1.1.6.0, and is capable of configuring the product in the role of a federation Service Provider for a SAML 2.0 SP-initiated POST profile with an enterprise Identity Provider that is enabled for SAML 2.0.

Finally, the steps below are for a deployment on Oracle Enterprise Linux, and the steps for other operating systems will differ slightly.

Main Article

Loopback Test

The loopback test utilizes the FA OIF instance as both IDP and SP, and this is a functional test that allows a confirmation that OIF is operating properly. Open a browser and go to the EM Fusion Middleware Control Console, logging in as the WLS administrator (e.g., ‘weblogic’):

fed091

Right-click on OIF(11.1.1.2.0) and go to Administration > Identity Provider:

fed092

Ensure Enable Identity Provider is checked. If not, check it and click Apply. Right-click on OIF(11.1.1.2.0) and go to Administration > Identity Provider:

fed093

Ensure Enable Service Provider is checked. If not, check it and click Apply. Access the IDP metadata by going to the following URL (substitute actual values to this example):

http://sso.mycompany.com:7777/fed/idp/metadata

fed094

Save the data as idp_metadata.xml:

fed095

Access the SP metadata by going to the following URL (substitute actual values to this example):

http://sso.mycompany.com:7777/fed/sp/metadata

fed096

Save the data as sp_metadata.xml:

fed097

Right-click on OIF(11.1.1.2.0) and go to Administration > Federations and click Add:

fed098

Click Browse:

fed099

Select idp_metadata.xml and click Open:

fed100

Ensure Enable Provider is checked, enter IDP for Loopback Test for Description and click OK:

fed101

Click Add:

fed102

Click Browse:

fed103

Select sp_metadata.xml and click Open:

fed104

Ensure Enable Provider is checked, enter SP for Loopback Test for Description and click OK:

fed105

Right-click on OIF(11.1.1.2.0) and go to Administration > Authentication Engines:

fed106

Change Default Authentication Engine to LDAP Directory and click Apply:

fed107

 

Create a Test Webpage for Federated SSO

Creating a webpage for federated SSO testing allows for validating the federation configuration without affecting FA. Open a terminal window and navigate to the htdocs directory for the IDM WebTier, e.g., /u01/app/oracle/admin/web1/config/OHS/ohs1/htdocs. Create a directory named ‘oiftest’ and copy index.html from the parent directory to this directory and open it in an editor:

fed108

Replace the text with “This page was reached via OIF Federated SSO” and save:

fed109

Rename the file as oiftest.html:

fed110

 

Selecting a Test Account for Federation SSO Testing

The loopback test requires that an account in OID that has an email address populated be used. One can create a new test account, or use an existing account. For this article, the ‘oaamadmin’ account is used for this purpose. In either case, confirm the suitability of the account by opening a browser and navigating to ODSM:

fed111

Connect to OID as cn=orcladmin:

fed112

Click on the Data Browser tab and navigate to the account that will be used (cn=oaamadmin in this example). Ensure that the email address is populated (if not, enter a dummy email address and click Apply):

fed113

 

Test IDP-Initiated SSO

To confirm that OIF is functioning properly, the following URL will be tested (substitute actual values for the example values):

http://tester.mycompany.com:7499/fed/idp/initiatesso?providerid=http://tester.mycompany.com:7499/fed/sp&returnurl=http://tester.mycompany.com:7777/oiftest/oiftest.html

The first element of the URLs specifies the IDP that the user will authenticated against. The second element specifies the SP that acts as a gateway to a remote resource, and the last element specifies the target resource that the user wishes to access behind the SP. Open a web browser and enter the URL in the address bar:

fed114

The browser will redirect to the login page controlled by the IDP. Enter the credentials for the test account and click Sign In:

fed115

If login is successful, the browser will redirect to the target page (oiftest.html):

fed116

 

Backing Out the Loopback Test Configuration

The configuration changes for the loopback test must be backed out before the final configuration for FA can be completed.Go to the EM Fusion Middleware Control Console, logging in as the WLS administrator (e.g., ‘weblogic’):

fed117

Right-click on OIF(11.1.1.2.0) and go to Administration > Authentication Engines:

fed118

Change Default Authentication Engine to Oracle Access Manager 11g and click Apply:

fed119

Right-click on OIF(11.1.1.2.0) and go to Administration > Identity Provider:

fed120

Uncheck Enable Identity Provider and click Apply:

fed121

Right-click on OIF(11.1.1.2.0) and go to Administration > Federations. Highlight the IDP for Loopback Testing entry and click Delete:

fed122

Click Yes:

fed123

The Federations page should now look like this:

fed124

 

At this point, the WLS AdminServer and OIF managed server should be restarted.

 

Import/Export Metadata for Enterprise Federation

In this section, the process for establishing a federation trust between the FA OIF instance and the enterprise IDP is detailed. In this example, the SAML 2.0 profile will be configured with email address as the Name ID for the federation.

Export SP Metadata

Access the SP metadata by going to the following URL (substitute actual values to this example):

http://sso.mycompany.com:7777/fed/sp/metadata

fed125

Save the data as sp_metadata.xml:

fed126

This file needs to be sent to the administator of the enterprise IDP for import to the IDP federation server(s).

Import Enterprise IDP Metadata

The enterprise IDP administrator must send a copy of the IDP metadata for import into OIF. This file will look something like this:

<?xml version=”1.0″ standalone=”yes” ?>
<md:EntityDescriptor xmlns:md=”urn:oasis:names:tc:SAML:2.0:metadata” xmlns:dsig=”http://www.w3.org/2000/09/xmldsig#” validUntil=”2013-08-09T17:38:44Z” entityID=”http://oamtest1.mycompany.com:7777/fed/idp”><md:IDPSSODescriptor protocolSupportEnumeration=”urn:oasis:names:tc:SAML:2.0:protocol” WantAuthnRequestsSigned=”false”><md:KeyDescriptor use=”signing”><dsig:KeyInfo><dsig:X509Data><dsig:X509Certificate>MIICIzCCAYygAwIBAgIBLDANBgkqhkiG9w0BAQQFADA1MTMwMQYDVQQDEypvYW10
ZXN0MS5teWNvbXBhbnkuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwHhcNMTMwNzA4
MDI1MTI0WhcNMTQwNzA4MDI1MTI0WjA1MTMwMQYDVQQDEypvYW10ZXN0MS5teWNv
bXBhbnkuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAMKwfLKXxDgb/ZR2m0e0uffGA42fwTw4leH3bPzgnkCXF+3myCBx
/Bdca8wQ1WwDScq0Td1YjfNxYeAC7OGWn9zg52ismHMVupt8cAG6aNzolex+fg+U
j9o5OZSeu4NBNH+UkQJpr6kQDttLN+3cdFZ994Fa9L86r7a8GZWsrLrdAgMBAAGj
QzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwfwADAdBgNVHQ4EFgQU
GiQjlFJFodSCDFhDmCTTVbnGgIUwDQYJKoZIhvcNAQEEBQADgYEAUiQ7cLhZfkws
3UrPCylZB0XyiSMxwAEJBKfqGjsL9LZUOnRJC82xiCfJbRswN6e0iUYKEZb5s7S3
ttdEQZiBraih/CBaVkPNX6XTzYnoJz0kUNKoqDs9BKG5aLK3c+DvTze3vh1YWRXm
FnJHKZL5Rauk2pfSkNAX5ru0U3YyfUU=
</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo></md:KeyDescriptor><md:KeyDescriptor use=”encryption”><dsig:KeyInfo><dsig:X509Data><dsig:X509Certificate>MIICKTCCAZKgAwIBAgIBBjANBgkqhkiG9w0BAQQFADA4MTYwNAYDVQQDEy1vYW10
ZXN0MS5teWNvbXBhbnkuY29tIEVuY3J5cHRpb24gQ2VydGlmaWNhdGUwHhcNMTMw
NzA4MDI1MTI0WhcNMTQwNzA4MDI1MTI0WjA4MTYwNAYDVQQDEy1vYW10ZXN0MS5t
eWNvbXBhbnkuY29tIEVuY3J5cHRpb24gQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAIdsJdw2KPezfstIDDUbn2nZCbZZxtjf+YivtK3jcf/Z
JjPrDGYnOUfeYuvkf8IqyTDydiN39tgqvu0KGmX9cTvsfyHys3xCNRzL8RGqQbsr
DXEZGUtIHK34PAJazvXttgiGehZZ3JHpfMEpHYpRs1M4YGdQ1u1GiuCgJwqhJ0mx
AgMBAAGjQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwfwADAdBgNV
HQ4EFgQUqDkr9KzkA7Rh2dNM78VVqOj5lNgwDQYJKoZIhvcNAQEEBQADgYEAGUGs
EfA6LjVZ9/tqgJ4XJWzB9L1gLsph/MVWcgeaXj04f3DPXIfKVlcQy7Nx8TmdnLlZ
vNoJxNap7GCOc9RpLvIRlN9qHx1zHwAmO+ah+Z7gHmmlfSlFtlrt50Ck6/hswkrW
+8ZgFL0+q5EW/nw7vynwPDkA4cFMY7qiHUY3kjc=
</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><md:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#rsa-1_5″></md:EncryptionMethod><md:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes128-cbc”></md:EncryptionMethod><md:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes192-cbc”></md:EncryptionMethod><md:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes256-cbc”></md:EncryptionMethod><md:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#tripledes-cbc”></md:EncryptionMethod></md:KeyDescriptor><md:ArtifactResolutionService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP” Location=”http://oamtest1.mycompany.com:7777/fed/idp/soap” index=”1″ isDefault=”true”></md:ArtifactResolutionService><md:SingleLogoutService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″ ResponseLocation=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″></md:SingleLogoutService><md:SingleLogoutService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″ ResponseLocation=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″></md:SingleLogoutService><md:ManageNameIDService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″ ResponseLocation=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″></md:ManageNameIDService><md:ManageNameIDService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP” Location=”http://oamtest1.mycompany.com:7777/fed/idp/soap”></md:ManageNameIDService><md:ManageNameIDService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″ ResponseLocation=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″></md:ManageNameIDService><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><md:SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″></md:SingleSignOnService><md:SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=”http://oamtest1.mycompany.com:7777/fed/idp/samlv20″></md:SingleSignOnService></md:IDPSSODescriptor></md:EntityDescriptor>

Of note here is the Entity ID:

entityID=”http://oamtest1.mycompany.com:7777/fed/idp”

This is the URL that the IDP is accessed from, and it should be verified at this point that this URL is reachable by an end user.

Open a browser and go to the EM Fusion Middleware Control Console, logging in as the WLS administrator (e.g., ‘weblogic’):

fed127

Right-click on OIF(11.1.1.2.0) and go to Administration > Federations:

fed128

Click Add:

fed129

Check Enable Provider and click Browse:

fed130

Navigate to the enterprise IDP metadata file, click to highlight it and click Open:

fed131

Enter a description (e.g., Enterprise IDP Metadata) and click OK:

fed132

Testing Federation with the OIF Test SP Module

The new federation agreement can be tested using the built-in Test SP authentication engine. In Enterprise Manager, navigate to Administration > Service Provider Integration Modules:

fed133

Click on the Test SP Engine tab:

fed134

Ensure Enable SP Engine is checked (if not, check it and click Apply):

fed135

Prepare a Test Account

In order for federation to work, the test account must be present in the OIF identity store as well as the enterprise IDP identity store, and the email address for this account must be present in both places with the identical value. By default, this is the Name ID that the two federation endpoints will use to identify a user.

Open a browser and manually clear cookies and any active sessions:

fed136

Enter the following URL (substitute actual values for the example below):

http://sso.mycompany.com:7777/fed/user/testspsso

fed137

Check Use Default Configuration and click Start SSO:

fed138

The browser session will be redirected to the enterprise IDP to authenticate:

fed139

Enter the credentials of the test account to login:

fed140

If successful, the following summary page will be displayed:

fed141

 

Cutover Fusion Applications SSO to Federated SSO

Open a browser and navigate to the OAM Administration Console, and log in as the OAM administrator:

fed142

Navigate to Authentication Schemes > FAAuthScheme:

fed143

Change the following parameters:

Challenge URL: http://sso.mycompany.com:7777/fed/user/spoam11g (substitute actual hostname and port here)

Challenge Parameters: TAPPartnerId=OIFDAPPartner

and click Apply:

fed144

Ensure the change is successful:

fed145

 

The configuration is now complete and can be tested by logging in to the FA homepage.

Comments

  1. paul-wgap says:

    Hi Jennifer/Steve,

    I could not find anywhere to post a question in general, so I found the article which seems closest and am hoping you might be able to point me in the right direction.

    We have the following situation:
    We use OAM 11.1.2.2 and federated authentication using an external Identity Provider.
    For all but one of our applications, the normal 2-step authentication is fine, i.e. (1) authenticate with the external IDP via SAML, then (2) check that a corresponding user exists locally (in OID).

    However, for one application, the users will not be in our local OID, so we want to ignore that situation.

    We thought we could define a 2nd IDP, which would simply always return a fixed entry in OID (e.g. PUBLIC), but Oracle has told us OAM does not support 2 IDPs with the same service URL.

    So one of our ideas would be a custom authentication plug-in which could be included in the orchestration steps of the authentication module.

    But it seems to me this custom authentication plug-in would have to be a modified version of one of he out-of-the-box federated authentication plug-ins, which would have 2 different behaviours: (1) the normal 2-step authentication for all but the one application URL, and (2) only the single step authentication for the one application which needs this.

    Do you have any thoughts on this and/or know anywhere else I can turn to for advice?

    Thanksk,
    -paul

Add Your Comment