Oracle Technology Network

Transient and Mapping Federations with Oracle Identity Federation (OIF)

<Do not delete this text because it is a placeholder for the generated list of "main" topics when run in a browser>

Purpose

In this tutorial, you learn how to register partners so that the Service Provider and the Identity Provider trust each other. You also learn how to configure two kinds of federations: a transient federation and a mapped federation.

Time to Complete

Approximately 1 hour.

Overview

OIF establishes trust based on X.509 certificates. These certificates can be passed back and forth via XML files to identify which systems to trust. Once you trust a partner system, it can be configured as either a Service Provider, an Identity Provider, or both. When a user tries to access a resource on the Service Provider (typically via a Web browser), the user's identity can be authenticated ("asserted") by a separate Identity Provider. Identity across security domains is a federation. The federation can be transient (one-sided) or mapped (two-sided). There are other forms of federations as well. In this Oracle By Example course, you will learn how to do transient and mapped federations.

Scenario

Background: Your company's users have access to a Web-based application that runs on a separate server in a separate company. Your company and the other company are considered separate security domains. For purposes of naming, assume that your company is MyCorp and the application is a life insurance benefits package hosted by MyLife Inc. The security for the benefits application requires authentication for a group of users that is not necessarily the same users that would be locally known on the application server. You must configure OIF on both your company's computer and the insurance company's computer. Your company's computer will be the Identity Provider (IdP) and the insurance company's computer will be the Service Provider (SP).

There are two scenarios:

You will configure both types of federations. Adding user Joe to both systems and the synchronization of both systems' directories is assumed to be manual for this example.

Hardware and Software Requirements

The following is a list of hardware and software requirements:

Prerequisites

Before starting this tutorial, you should:

.

Verify that OIF is installed and configured as per the OBE Installing Oracle Identity Federation

Verifying the OIF Environment

To verify that the OIF environment is installed and configured properly, and that all services are started, perform the following steps:

.

Open a Web browser session for both the Identity Provider (IdP) and the Service Provider (SP) simultaneously. Go to URL http://hostidp:7001/em and URL http://hostsp:7001/em to run the Enterprise Manager 11g Fusion Middleware Control. Log in to Enterprise Manager with a User Name of weblogic and a password of Welcome1 on both systems. The password will display as a series of dots. Click Login.

Don't confuse this Enterprise Manager (usually port:7001) with the Database Enterprise Manager (usually port:1158).
The use of tabs on a Web browser will make it easier to keep the changes to both systems in sync with each other. It is slightly faster to have the browser on a third system, and not running the browser on either of the two computers being configured.

 

.

Make sure that the Identity Provider computer is enabled only for providing Identity functionality. On the left navigation panel, click OIF(11.1.1.1.0). On the top pull-down menu, navigate to Oracle Identity Federation > Administration > Identity Provider.

Be mindful of which computer you are configuring. Make sure it is the IdP as shown in the red boxes.

Click the Common tab and make sure that Enable Identity Provider is selected. It is the default, so it should be checked already.

On the top pull-down menu, go Oracle Identity Federation > Administration > Service Provider. Click the Common tab and make sure that Enable Service Provider is deselected. It is the default, so it should be cleared. It is possible for a computer to be both an Identity Provider and a Service Provider simultaneously, but that complicates the example.

Since you changed something here, click Apply. You should see a Confirmation that "Changes have been applied."

 

.

Make sure that the Service Provider computer is enabled for only Service Providing functionality. This is doing the complementary step on the other computer. On the left navigation panel, click OIF(11.1.1.1.0). On the top pull-down menu, navigate to Oracle Identity Federation > Administration > Identity Provider.

Be mindful of which computer you are configuring. Make sure it is the SP as shown in the red boxes.

Click the Common tab and make sure that Enable Identity Provider is deselected. It is the default, so it should be cleared.

Since you changed something here, click Apply. You should see a Confirmation that "Changes have been applied."

On the top pull-down menu, go Oracle Identity Federation > Administration > Service Provider. Click the Common tab and make sure that Enable Service Provider is selected. It is the default, so it should be checked already. Deselect the Map Assertion to User Account. By not mapping, that makes it a transient federation. Since you changed something here, click Apply. You should see a Confirmation that "Changes have been applied."

 

Registering Federation Partners


The trust between computers is based on certificates from a mutually-trusted third party that issues digital encrypted certificates. This third party is called a Certificate Authority (CA). The certificates can be stored in an XML format. One standard kind of certificate is an X.509 format supporting Public-Key Infrastructures. To pass X.509 certificates back and forth so that the two partner systems trust each other, perform the following steps:

Exporting Metadata


.

Navigate to the Security and Trust panel. On the left navigation panel, click OIF(11.1.1.1.0). On the top pull-down menu, navigate to Oracle Identity Federation > Administration > Security and Trust.

You are going to do this for both systems. Make sure you are doing the Identity Provider (IdP) first. Not that it needs to be first, but just some way to make sure you do them in order. In a larger topology, you might have one IdP and several SPs.

 

.

Configure the Provider Metadata Settings on the Identity Provider host. Click the Provider Metadata tab. Select Require Signed Metadata and Sign Metadata.

Click Apply.

You should see a Confirmation that "Changes have been applied."

 

.

Generate the Identity Provider Metadata. Change the Provider Type pull-down menu to Identity Provider. Click Generate.

Note that you can generate metadata to support several kinds of protocols: SAML 2.0 and SAML 1.x.

 

.

Save the generated IdP SAML metadata file to the local PC. Click OK.

Note that the XML filename is created by a combination of hostname_port_function_protocol.xml where in this case hostname=hostidp.example.com and port=7499 and function=idp and protocol=saml20. Depending on your Web browser, this dialog box may look slightly different.

 

.

Configure the Provider Metadata Settings on the Service Provider host. Switch hosts and perform much the same steps on the other computer. Navigate to the Security and Trust panel. On the left navigation panel, click OIF(11.1.1.1.0). On the top pull-down menu, navigate to Oracle Identity Federation > Administration > Security and Trust. Click the Provider Metadata tab. Select Require Signed Metadata and Sign Metadata. Click Apply.

Make sure this is the SP computer as shown in the red boxes at the top. You should see a Confirmation that "Changes have been applied."

 

.

Generate the metadata.

By default the Provider Type pull-down already says Service Provider and SAML 2.0, so you do not need to change anything there.

 

.

Save the SP SAML metadata file to the local PC.

Note the generated XML filename for the SP metadata is slightly different than the one generated for the IdP. Depending on your Web browser, this dialog box may look slightly different.

 

.

Examine the SP SAML metadata using a Web Browser or XML editor (or as a last resort a text editor). Look for the source (hostsp.example.com shows in a half-dozen places) and the type of metadata (SAML:2.0 shows in a half-dozen places).

Continue scrolling down, looking for the signed X.509 certificates (two) and the kinds of services supported (HTTP-POST, HTTP-Redirect, HTTP-Artifact, and so on.)

Both the SP XML and the IdP XML files contain encrypted certificates that were included with the OIF product as demo code (hence not "real" certificates). In real life they would be issued by a Certificate Authority (CA) such as Verisign, Comodo, or GoDaddy.

 

Importing Metadata


.

On the SP computer, navigate to the Federations configuration panel. On the left navigation pane, click OIF(11.1.1.1.0). On the Oracle Identity Federation pull-down at the top, click Administration > Federations.

The XML files both reside on wherever your browser downloaded and saved them in the Export step. Depending on your level of paranoia, you might want to hand-carry the certificate files safely from one machine to another without sending them on the open Internet. Or you could simply sftp or ftp or even email the files where they need to reside to be accessible for the Import step.

 

.

Add a Trusted Provider. Click +Add.

Notice that currently there are no trusted providers.

 

.

Specify the idp_saml20.xml file that contains the IdP information for the SP to trust it. Click Browse to navigate to where you stored the exported metadata from the previous steps.

Be mindful of Opening the IdP file for the SP computer, and the SP file for the IdP computer.

Select the file that has the idp metadata information. The letters "idp" will be part of the host name as well as part of the file name. Click Open.

Click OK.

 

.

Confirm that the IdP is now trusted by the SP.

You should see Confirmation that the "Peer Provider(s) have been uploaded successfully."

 

.

On the IdP computer, click on OIF(11.1.1.1.0), then navigate to the Federations configuration panel. On the pull-down, navigate to Oracle Identity Federation > Administration > Federations.

 

.

Add a trusted provider.

This is similar to the steps done previously for the SP. Click +Add, click Browse, select the file that has the SP metadata. Click OK.

 

.

Confirm that the SP s now trusted by the IdP.

It is not unusual for there to be a many-to-one relationship of many Service Providers to the one Identity Provider. It is also possible, but less common, for there to be a reverse relationship where each of a pair of boxes is both an IdP and an SP.

 

Transient Federations

The function of a transient federation is to allow a user such as Ira who exists only on the Identity Provider OID to use an application (a "service") on the Service Provider without having a user account directly on the Service Provider OID. To do transient federations, perform the following steps:

.

On the SP computer, navigate to the Service Provider.

In the navigation pane on the left, click on OIF(11.1.1.1.0). In the Oracle Identity Federation pull-down at the top, click Administration > Service Provider.

 

.

Change the Assertion Settings to not require a user account at the SP.

Disable (deselect) Map Assertion to User Account. You may have already done this as the last step in Verifying the OIF Environment.

Click Apply. You should see Confirmation that the "Changes have been applied."

 

.

Test the transient federation first with a user only on the SP OID.

In a SEPARATE BROWSER, go to URL http://hostsp.example.com:7499/fed/user/testspsso to test the Service Provider Single Sign On. The reason for the separate browser is that you need to close the browser after each experiment to verify that the session cookies are cleared. If you simply close a tab on an open browser, that will not clear the session cookies.

  • Change the IdP Provider ID to http://hostidp.example.com:7499/fed/idp. It should be the only choice in the pull-down.
  • Change Authn Request Binding to HTTP POST.
  • Select Allow Federation Creation.
  • Change SSO Response Binding to HTTP POST.
  • Change Name ID Format to Email Address.
  • Click Start SSO.

Notice the URL was redirected to the IdP for authentication. Sue is only a local user in the SP OID, so should it work? (By way of review, Sue and Steve are defined only on the SP, Ira and Isabella are defined only on the IdP, and Bob is defined identically on Both.) Enter her case-sensitive name Sue and password Welcome1. Click Sign In.

It failed since she is not in the IdP OID. This is especially interesting since she asked for a resource on the SP and she has an account on the SP! Since it did not work, you don't have to close the browser because there never was a federation established nor a cookie for signon, but closing the browser here is still a good habit to get into between testing cases.

 

.

Test the transient federation second with a user only on the IdP OID.

Since the previous attempt failed, there are no cookies to clear. Sign on as Ira who is only listed in the IdP OID. Enter the password Welcome1 and click Sign In.

Notice the response comes from the SP stating that the assertion from the IdP says that Ira is who he says he is, based on a password stored at the IdP in an LDAP-enabled directory (in this case OID).

On the OIF Home page of the IdP, you can now see the federations generated for Ira in the red boxes.

From the Oracle Identify Federation pull-down, navigate to Administration > Identities.

From the Federated Identities tab, click Search. Ira should be listed as a federated identity based on SAML 2.0. If you want to repeat the experiment, you would have to delete the federation from here by selecting the User (in this case Ira) and clicking X Delete. Or you could close the browser and try signing in as another user who is listed only on the IdP, such as Isabella.

 

.

Test the transient federation lastly with a user such as Bob who is on both the SP and the IdP OID.

Close the browser with the previous federation result and reopen it and re-go to URL http://hostsp.example.com:7499/fed/user/testspsso.

  • Change the IdP Provider ID to http://hostidp.example.com:7499/fed/idp. It should be the only choice in the pull-down.
  • Change Authn Request Binding to HTTP POST.
  • Select Allow Federation Creation.
  • Change SSO Response Binding to HTTP POST.
  • Change Name ID Format to Email Address.
  • Click Start SSO.
  • Sign in as Bob.
It should be successful since Bob is listed in the IdP. The fact that he is also listed in the SP is coincidental.

 

Mapping Federations

Having a single point of administration (the IdP) for all the users is attractive, but less secure than having the user defined twice. To tighten the security, you can require that the user be defined on both the IdP and the SP, and have matching attributes. This is a mapped federation. To configure a mapped federation, perform the following steps:

.

On the SP, navigate to Service Provider Common.

On the Oracle Identity Federation pull-down, navigate to Administration > Service Provider.

 

.

Change the Mapping back to the default of enabled.

Select Map Assertion to User Account.

Click Apply. You should see a Confirmation.

 

.

Verify that Bob is listed in both the SP and the IdP OID Local Users.

On the SP computer, on the Oracle Identity Federation pull-down, navigate to Administration > Identities. Click the Local Users tab. Click Search. Note Bob is there.

On the IdP computer, on the Oracle Identity Federation pull-down, navigate to Administration > Identities. Click the Local Users tab. Click Search. Note Bob is here too. They don't have to match exactly for every attribute. The idea is that they are the same person but on two different systems. For example, one of the users could be listed as FirstName=Robert and the other as FirstName=Bob as long as their email was the same. Also one directory (MyCorp) might have a cubicle number while the MyLife directory might have a BloodPressure attribute, each with nothing corresponding on the other directory.

 

.

Test the mapped federation with Sue, Ira, and Bob.

Close the browser with the previous federation result and reopen it and re-go to URL http://hostsp.example.com:7499/fed/user/testspsso.

  • Change the IdP Provider ID to http://hostidp.example.com:7499/fed/idp. It should be the only choice in the pull-down.
  • Change Authn Request Binding to HTTP POST.
  • Select Allow Federation Creation.
  • Change SSO Response Binding to HTTP POST.
  • Change Name ID Format to Email Address.
  • Click Start SSO.

Try signing in as Sue.

Sue is listed only in the SP OID so it should fail.

Try signing in as Ira.

Ira is listed only in the Idp OID so it should fail as well. This used to work for transient federations, but you have tightened up the security so now the user needs to exist in both computers' OID.

Try signing in as Bob.

Since Bob is listed in both OIDs, this works.

 

Summary

Now the two computers at MyCorp and MyLife trust each other and can establish federations. In addition, the employees at MyCorp can access the life insurance benefits application hosted at MyLife. The security can be either looser (transient) or tighter (mapped) since both methods have been tested.

In this tutorial, you have learned how to:

Resources

Credits

Oracle Is The Information Company About Oracle | Oracle RSS Feeds | Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Your Privacy Rights