| Oracle® Identity Federation Administrator's Guide 10g (10.1.4.0.1) Part Number B25355-02 |
|
|
View PDF |
| Oracle® Identity Federation Administrator's Guide 10g (10.1.4.0.1) Part Number B25355-02 |
|
|
View PDF |
This chapter describes key deployment scenarios, including integration with identity and access management systems, Web servers, and back-end data stores. It contains these topics:
Oracle Identity Federation operates in a heterogeneous system environment, and is capable of working with a wide range of applications serving as identity providers, service providers, data stores, and web servers.
To resolve deployment issues and questions, refer to Chapter 2, "Planning Oracle Identity Federation Deployment", which provides extensive background information to help you plan your deployment:
"Architecture Options" provides details about supported protocols and profiles, and what to consider when evaluating deployment options.
"Sizing Guidelines" explains performance factors and provides topology recommendations.
"Implementation Checklist" provides a deployment checklist.
The next section provides step-by-step instructions for configuring Oracle Identity Federation to work with key components of the federated environment.
This section describes the steps needed to implement common Oracle Identity Federation deployment scenarios. It contains these sections:
Deploying Oracle Identity Federation with OracleAS Single Sign-On
Deploying Oracle Identity Federation with Oracle Access Manager
Deploying Oracle Identity Federation with a Sun Java System Web Server
Configuring Oracle Identity Federation to Use IBM Tivoli Directory Server as the Data Store
Integrating with Third-Party Identity & Access Management Modules
This section describes the steps needed to install and deploy Oracle Identity Federation so that it is integrated with OracleAS Single Sign-On.
Deployed in this manner, Oracle Identity Federation can leverage the authentication capabilities offered by OracleAS Single Sign-On when local user authentication is required. Oracle Identity Federation can:
act as an identity provider to authenticate a user and provide the user's authentication information to any third party, or
act as a service provider that consumes authentication data from an identity provider in order to authenticate a user.
Briefly, the steps to achieve this deployment are:
Install Oracle Identity Federation using the advanced installation mode, electing to store federation data in Oracle Internet Directory. Optionally, store transient data in a database.
Integrate Oracle Identity Federation with OracleAS Single Sign-On. This involves, among other things, updating the OracleAS Single Sign-On environment to add Oracle Identity Federation as an authentication mechanism, and associating the server instance with OracleAS Single Sign-On.
Update Oracle Identity Federation configuration to provide connection details for the OracleAS Single Sign-On and Oracle Internet Directory servers, and exchange metadata with peer providers in the Circle of Trust.
Detailed instructions for these steps follow.
Note:
Oracle Identity Federation does not support the ability to force re-challenging the user for credentials when integrated with OracleAS Single Sign-On. This means that Oracle Identity Federation cannot support use cases where reauthentication must be forced.For example, if an SP sends an AuthnRequest with ForceAuthn="true" to an Oracle Identity Federation IdP, and Oracle Identity Federation is integrated with OracleAS Single Sign-On, the ForceAuthn flag is ignored.
Install Oracle Identity Federation
Perform these installation steps:
Launch Oracle Universal Installer. Select the Oracle Identity Federation 10g product, and choose the Advanced installation method.
On the Specify Federation Data Store screen, select Oracle Internet Directory as the directory server type, and enter information about the server in the input fields. In this example, the Oracle Internet Directory server hostname and port, respectively, are infra.example.com and 389:
| Field | Sample Value |
|---|---|
| Host | infra.example.com |
| Port | 389 |
| Bind DN | cn=orcladmin |
| Password | password for orcladmin |
Note:
These LDAP connection credentials are used only to update the directory with the federation data schema. Different credentials are typically configured later for runtime directory access.If you selected the Federation Transient Data in Database option, a database user must be available with privileges to create tables.
Rather than using system table space for the transient data, it is recommended that table space be allocated to this user. For example, using SQL*Plus and connecting to the database as user sysdba, the following commands create a user named oifdb and allocate table space for that user:
create tablespace ts_oifdb logging datafile '/scratch/Oracle/i0120/oradata/i0120/ts_oifdb.dbf' size 512m autoextend on extent management local; create user oifdb identified by oifdb default tablespace ts_oifdb; grant connect,resource to oifdb; alter user oifdb account unlock;
On the Specify Federation Transient Data Store screen, enter your database connection information - username, password, host, port, and Web service name.
Complete the remainder of the Oracle Identity Federation installation, specifying the federation server ID, instance name, and administrator password.
Note:
For installation details, see "Advanced Installation Procedure".Integrate Oracle Identity Federation and OracleAS Single Sign-On
These steps 1) make the Oracle Identity Federation server host known to OracleAS Single Sign-On, and 2) associate the Oracle Identity Federation instance with OracleAS Single Sign-On.
In the Oracle IdM/Infrastructure home, edit the sso/conf/policy.properties file by uncommenting and modifying the following lines, where oif.example.com:7780 is the host and port of the Oracle Identity Federation server:
SASSOAuthnUrl = http\://oif.example.com\:7780/sso/authn SASSOLogoutUrl = http\://oif.example.com\:7780/sso/jsp/sasso_logout_success.jsp SASSOAuthLevel = MediumHighSecurity
Add the following lines to the sso/conf/policy.properties file, where content.example.com:8888 is the host and port of the resource server:
content.example.com\:8888 = MediumHighSecurity
MediumHighSecurity_AuthPlugin =
oracle.security.sso.server.auth.SASSOAuth
Copy the SSO keystore from the Oracle Identity Federation home to the Infrastructure home. For example:
cp OIF_HOME/sso/conf/keystore INFRA_HOME/sso/conf/
Register partner applications with OracleAS Single Sign-On as usual. For example, if you have a resource at /scratch/protected/index.html, with a virtual host on 140.87.26.53:8888, make these edits to the Apache/Apache/conf/httpd.conf file in the Infrastructure home:
Add one of these lines before <IfDefine SSL>, at the end of the LoadModule section:
For Linux:
LoadModule osso_module libexec/mod_osso.so
For Windows:
LoadModule osso_module modules/ApacheModuleOSSO.DLL
Also for Windows, at the end of the AddModule section, before <IfDefine SSL>, add the following line:
AddModule mod_osso.c
Add these lines before "# Include the configuration files needed for mod_oc4j":
Listen 8888
NameVirtualHost 140.87.26.53:8888
<VirtualHost 140.87.26.53:8888>
ServerName content.example.com
DocumentRoot "/scratch/protected"
OssoConfigFile
"/scratch/Oracle/i0120/Apache/Apache/conf/osso/osso-app.conf"
OssoIpCheck off
<Location /index.html>
AuthType basic
Require valid-user
</Location>
</VirtualHost>
Run the ssoreg script, which is ssoreg.sh on Linux, and ssoreg.bat on Windows. For example:
sso/bin/ssoreg.sh -oracle_home_path /scratch/Oracle/i0120
–site_name content.example.com –config_mod_osso TRUE
–mod_osso_url http://content.example.com:8888 –virtualhost
–config_file
/scratch/Oracle/i0120/Apache/Apache/conf/osso/osso-app.conf
Restart Infrastructure:
opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY opmn/bin/opmnctl restartproc process-type=HTTP_Server
To associate the Oracle Identity Federation instance with OracleAS Single Sign-On, open the Oracle Identity Federation Enterprise Manager console in a web browser. For example:
http://infra.example.com:1810/emd/console
Perform these steps:
Go to Infrastructure -> Identity Management and click the Change button.
Enter the Oracle Internet Directory host and port, and click Next.
Enter the Oracle Internet Directory username (for example cn=orcladmin) and password, and click Next, then Finish.
From the Enterprise Manager main page, restart Oracle HTTP Server, Home, and OC4J_FED.
Configure Oracle Identity Federation
These steps 1) provide Oracle Identity Federation with the information needed to connect to data stores, and 2) update and distribute the Oracle Identity Federation metadata to peer providers.
Open the Oracle Identity Federation administration console in a web browser:
http://oif.example.com:7780/fedadmin
Log in as oif_admin.
On the IdM Data Stores -> User Data Store screen, select OracleAS Single Sign-On and enter the connection information. For example:
| Field | Example Value |
|---|---|
| Connection URL(s): | ldap://infra.example.com:389
This is the Oracle Internet Directory instance used by OracleAS Single Sign-On. |
| Bind DN: | cn=orcladmin |
| Password: | the password for orcladmin |
| User ID Attribute: | uid |
| User Description Attribute: | uid |
| Person Object Class: | inetorgperson |
| Base DN: | dc=example,dc=com |
| Other properties' default values | |
| OSSO Login URL: | http://infra.example.com:7777/sso/auth |
| OSSO Logout URL: | http://infra.example.com:7777/sso/logout |
On the IdM Data Stores -> Federation Data Store screen, select LDAP Directory and enter the connection information. For example:
| Field | Sample Value |
|---|---|
| Connection URL(s): | ldap://infra.example.com:389
This is the Oracle Internet Directory instance used by OracleAS Single Sign-On. |
| Bind DN: | cn=orcladmin |
| Password: | the password for orcladmin |
| User Federation Record Context: | cn=fed,dc=example,dc=com |
| LDAP Container Object Class: | <blank> |
| Unique Federation ID Attribute: | <blank> |
Click Save.
Go to the Oracle Identity Federation Enterprise Manager console and restart OC4J_FED.
Go to the Oracle Identity Federation administration console, and navigate to the Server Configuration -> Circle of Trust screen.
In the Add Trusted Provider section, browse to the file system location of a peer provider's metadata XML document, and enter descriptive text for that provider. Click Add, then click Done.Click Refresh Server.
If configuring Oracle Identity Federation to be a service provider, go to the Server Configuration -> Service Provider -> Global Settings screen, and select a Default SSO Identity Provider from the list box.
Click Save, then Refresh Server.
Each peer provider in the circle of trust will need a copy of the Oracle Identity Federation metadata XML document. Start by accessing the metadata URL for the particular server role (SP or IdP) and the federation protocol version (Liberty 1.1, 1.2 or SAML 2.0) in question. For example:
http://oif.example.com:7780/fed/sp/metadatav20
http://oif.example.com:7780/fed/idp/metadatav20
Save the XML file retrieved from the URL, and distribute it to the other providers in the circle of trust. If setting up another Oracle Identity Federation instance as part of the circle of trust, this is the file you would load using Add Trusted Provider on the Circle of Trust screen.
Take these steps to test your federated single sign-on setup:
Use a web browser to access a protected resource. When prompted by the Identity Provider, log in using credentials in the IdP's domain. When prompted by the Service Provider, log in using credentials in the SP's domain. You should now be redirected to the protected resource.
Log out, and then try to access the protected resource again. You should be prompted for login only by the Identity Provider.
This section describes the steps needed to install and deploy Oracle Identity Federation so that it is integrated with Oracle Access Manager. The steps illustrate a deployment scenario consisting of two nodes:
Node A, referred to as host_a (and with an associated URL of the type host-a.us.oracle.com), is a service provider (SP) type server.
Node B, referred to as host_b (and with an associated URL of the type host-b.us.oracle.com), is an identity provider (IdP) type server.
The section is broken out into separate instructions for the different component installation and deployment tasks:
This section explains how to install OracleAS Infrastructure.
Note:
You only need to install the OracleAS Infrastructure with Oracle Access Manager if Oracle Access Manager is going to use Oracle Internet Directory as its directory. Otherwise, the OracleAS Infrastructure does not need to be installed.Launch Oracle Universal Installer, and select the Oracle Application Server Infrastructure 10g installation option.
Select Identity Management and Metadata Repository.
Use the default configuration options.
After installation is completed, establish database connection.
Run the coraenv script to set the proper values of the ORACLE_SID and ORACLE_HOME variables.
Connect to the database:
sqlplus '/ as sysdba'
Run the following SQL commands:
create tablespace ts_fd
logging
datafile '/scratch/aswu/Oracle/i0120/oradata/i0120/ts_fd01.dbf'
size 512m autoextend off,
'/scratch/aswu/Oracle/i0120/oradata/i0120/ts_fd02.dbf'
size 512m autoextend off
extent management local;
create user fd identified by fd default tablespace ts_fd; grant connect,resource to fd; alter user fd account unlock;
Several Oracle Access Manager components must be installed for use with Oracle Identity Federation:
Identity Server
WebPass installed in a Web server
Access Server
Oracle Access Manager (administration UI) installed on the same Web server as WebPass
if the Oracle Identity Federation or Oracle Access Manager site is a service provider (SP), WebGate agents installed on each Web server providing resources or services that are available to federated users
Refer to the Oracle Access Manager Installation Guide for details.
Considerations for Oracle Access Manager Installation
When installing and deploying Oracle Access Manager, pay special attention to issues critical for integration with Oracle Identity Federation:
When configuring the Access Server entry in the Access Manager console, set Access Management Service to On.
Note:
By default, Access Management Service is set to Off. Oracle Identity Federation requires that this field be set to On.See the Oracle Access Manager Access Administration Guide for details.
When enabling default policies, it is highly recommended that you set up the Oracle Access and Identity Basic Over LDAP authentication scheme (previously known as the NetPoint Basic Over LDAP authentication scheme). If this is not done, you will need to configure a basic scheme manually.
See the Oracle Access Manager Access Administration Guide for details.
As mentioned earlier, WebGate agents must be installed on each Web server providing resources or services available to federated users if the Oracle Identity Federation or Oracle Access Manager site is a service provider (SP). Note the following when configuring Webgates:
The Access Management Service setting must match the setting for the Access Server(s) used by the WebGate. So, if the WebGate uses the same Access Server(s) as Oracle Identity Federation will use, then it must be configured with the Access Management Service set to On. It is also possible for a WebGate to use a different Access Server instance(s) (in the same domain) with the Access Management Service set to Off, in which case the Web setting would be Off as well.
It is normal practice to set the Primary HTTP Cookie Domain to enable Oracle Access Manager single sign-on across web servers with installed WebGates. At a minimum, the cookie domain must include the Oracle Identity Federation host and at least one WebGate-protected web server. For example, if Oracle Identity Federation is on the host oif.us.company.com and the Web server is www.us.company.com, the domain setting should be.us.company.com or.company.com. If the Web server is www.company.com, the domain setting should be.company.com. Note: The default AccessGate setting for the cookie domain is empty (no domain), which will only work in a very atypical deployment where Oracle Identity Federation and all protected resources reside on the same host.
This section explains how to install Oracle Identity Federation for use with Oracle Access Manager. This is a brief summary of the necessary steps. For details, see "Advanced Installation Procedure".
Launch Oracle Universal Installer, and select the Oracle Identity Federation 10g installation option.
Select the Advanced installation method.
In Select Configuration Options, select Federation Data in LDAP Server and Federation Transient Data in Database.
In Specify Federation Data Store, provide this information:
Server Type - Oracle Internet Directory
Host/Port - the LDAP server host and port
Bind DN - cn=orcladmin
In Specify Federation Transient Data Store, provide this information:
Username
Password
Host, Port and Service Name - the database for transient data
This section explains how to integrate Oracle Identity Federation and Oracle Access Manager. This includes certain steps in both environments, such as configuring an AccessGate for Oracle Identity Federation (in Oracle Access Manager) and setting data store and other configuration parameters (in Oracle Identity Federation).
See Also:
See the Oracle Access Manager Access Administration Guide for details.Use the Access System Console http://AMhost:AMport/access/oblix (where AMhost:AMport is the web server where you installed WebPass and Access Manager) to configure an AccessGate for Oracle Identity Federation.
Select the Access System Configuration tab.
Select the Add New AccessGate link from the console panel.
Configure the AccessGate as follows, replacing the values in italics with your own values:
Note:
The AccessGate can have any name of your own choosing. It is named OIF in this example only for illustration.AccessGate Name: OIF Password: OIF-PASSWORD Hostname: OIF-HOST Port: OIF-PORT Transport Security: Match the Access Servers to be configured in Step d. Access Management Service: On Primary HTTP Cookie Domain: .company.com (Note: As noted in the WebGate configuration, the Primary HTTP Cookie Domain configured for Oracle Identity Federation must match the Primary HTTP Cookie Domains configured for the WebGates protecting the content to be accessed by federated users.) Preferred HTTP Host: OIF-HOST
Click Save.
Click List Access Server.
Click Add.
Select one or more servers from drop-down menu. Note: All selected Access Servers must have Access Management Service On.
Number of connections: 1
Click Add.
Use the Access System Console to configure the Fed HostID, if required.
Select the Access System Configuration tab.
Select the Host Identifiers link from the console panel.
If no host identifiers are defined, you do not need the Fed HostID. Skip to Step 3.
If host identifiers are defined, click the Add button.
Name: Fed HostID
Note: Enter the same fixed value for all supported languages.
Hostname variables: OIF-HOST:OIF-PORT
Note: If OIF-PORT is 80 or 443, also include OIF-HOST.
Click Save.
Install the Access Server SDK:
Run the AccessServerSDK installer (for example, Oracle_Access_Manager10_1_4_0_1_linux_AccessServerSDK) under OIF_HOME/fed/shareid/.
If installing on Linux, set the LD_ASSUME_KERNEL environment variable.
Open the Enterprise Manager console for the Oracle Identity Federation installation in a web browser. For example:
http://oif.example.org:1810/emd/console
Perform these steps:
- Under System Components, click the link for OC4J_FED.
- Go to Administration - > Server Properties and, under Environment Variables, click Add Environment Variable.
- In the new entry, enter LD_ASSUME_KERNEL in the Name field, and enter 2.4.19 in the Value field. Leave the Append checkbox unchecked.
- Click Apply.
- Click OK to restart the OC4J_FED container.
Go to the Oracle Identity Federation administration console at http://OIF-HOST:OIF-PORT/oifadmin. Click on the IdM Data Stores tab.
Note:
Substitute parameter values (bind DN, password, DNs, and so on) as required for your directory.For the federation data store:
Bind DN: cn=orcladmin
Password: your-password
User Federation Record Context: cn=fed,dc=us,dc=oracle,dc=com
For the user data store:
Active Repository: Oracle Access Manager Connection URL(s): ldap://LDAP-Server-Host:Port Bind DN: cn=orcladmin Password: your-password User ID Attribute: uid User Description Attribute: uid Person Object Class: inetOrgPerson Base DN: dc=us,dc=oracle,dc=com
For Oracle Access Manager configuration parameters:
Master Admin Login ID: orcladmin
Master Admin Password: your-password
Authorization result for unprotected resources: Allow
Oracle Access Manager Cookie Domain: .company.com
Basic Authentication Scheme Name: Oracle Access and Identity authentication scheme
Note:
Oracle Access Manager Cookie Domain: As noted in the WebGate configuration, the Primary HTTP Cookie Domain configured for Oracle Identity Federation must match the Primary HTTP Cookie Domains configured for the WebGates protecting content to be accessed by federated users.
Basic Authentication Scheme Name: Use the Access System Console (http://AMhost:AMport/access/oblix) to find a suitable basic authentication scheme. If you enabled the default policies when you installed Oracle Access Manager (by selecting Access Manager in the Oracle Access Manager console, checking the two policies and clicking Enable), you can use the basic scheme created for those policies:
For Oracle Access Manager 10.1.4: Oracle Access and Identity Basic Over LDAP authentication scheme
For COREid 7.0.4: NetPoint Basic Over LDAP
If no basic schemes are configured, you must set one up following instructions in the Oracle Access Manager Access Administration Guide. You can cut and paste the display name for the chosen basic scheme from the Access System Console to the Oracle Identity Federation User Data Store page.
Click Apply.
Use these credentials for the Access Server:
Access Server Host Name: access-server-host
Note:
This must be one of the servers configured in step 1d.Access Server Port: access-server-port
Access Gate ID: OIF
Access Gate Password: OIF-password
Connection Type: must match the access servers
Restart the Oracle Identity Federation server.
To make sure that the integration is complete:
Log into the Access System Console http://AMhost:AMport/access/oblix/.
Click Access Manager.
Check Fed Domain created in My Policy Domains.
To create a resource protected by Oracle Identity Federation (as a service provider):
Follow the steps for protecting resources in the Oracle Access Manager Access Administration Guide, in the chapter Protecting Resources with Policy Domains.
Change the authentication scheme to one of:
Fed SSO - SAML2.0/Liberty 1.x – to use SAML 2 or Liberty 1.1 or 1.2 SSO profiles
Fed SSO - WS-Federation – to use the WS-Federation Passive Requester SSO profile
Fed SSO - SAML 1.x – to use SAML 1.0 or 1.1 SSO profiles
You may need to ensure that the security levels of any existing authentication schemes and the Fed SSO authentication schemes are configured in Oracle Access Manager such that the Fed SSO scheme is selected when the protected resource is accessed. For example, if your Fed SSO authentication scheme has security level 1, and your basic login authentication scheme has security level 2, then the user will always be challenged for login even if federated single sign-on succeeds.
Note:
The choice is determined by the protocols that the partner identity providers support. If the same resource will be accessed by partners requiring different protocols, you must set up separate policies with different resource URLs to map the requests to the appropriate authentication scheme. For example, to provide access to a resource/my-resource using both SAML 2 and WS-Federation, you can set up:
a policy for a resource /my-resource-saml2 that uses the Fed SSO – SAML2.0/Liberty 1.x scheme, and
a policy for a resource /my-resource-wsfed that uses the Fed SSO – WS-Federation scheme.
You must then configure the web server to map these pseudonymous URLs to the actual /my-resource URL.
This section describes how to integrate Oracle Identity Federation with eTrust SiteMinder. Deployed in this manner, Oracle Identity Federation can leverage the identity and access management capabilities of eTrust SiteMinder.
This discussion assumes the following framework:
eTrust SiteMinder is the Identity and Access Management Server.
The eTrust SiteMinder User Directory is an LDAP server.
The User Data Store used by Oracle Identity Federation is an RDBMS.
The SP functionality will not be exercised, so it is not necessary to install the SiteMinder native library on the eTrust SiteMinder Policy Server.
Note:
Oracle Identity Federation requires certain eTrust SiteMinder policy objects to be created on the policy server. Oracle Identity Federation normally creates these automatically at initialization with the eTrust SiteMinder Policy Server, but they may also be created manually. Examples of policy objects created by Oracle Identity Federation are provided in "eTrust SiteMinder Policy Objects".This chapter contains the following topics:
See Also:
"Additional eTrust SiteMinder Configuration" for more information about eTrust SiteMinder integration with Oracle Identity Federation.You must meet the following requirements to integrate with eTrust SiteMinder:
eTrust SiteMinder SDK 5.5 must be installed on the Oracle Identity Federation machine.
The eTrust SiteMinder Policy Server must be at version 5.5.
In this deployment, Oracle Identity Federation will act as an eTrust SiteMinder Agent, using the eTrust SiteMinder SDK to communicate with the eTrust SiteMinder Policy Server. Perform these steps to install the SDK:
Install the eTrust SiteMinder SDK Version 5.5 to the $ORACLE_HOME/fed/shareid/SiteMinder directory.
Restart the OC4J_FED instance.
Define the database that will act as the user data store for Oracle Identity Federation as a DataSource in Oracle Application Server.
The steps to define such a DataSource are as follows:
Log in to the EM console of your Oracle Identity Federation instance and navigate to OC4J_FED - > Administration - > Data Sources.
Create a new data source using the following example as a guide:
Name: myDS
Data Source Class: com.evermind.sql.DriverManagerDataSource
JDBC URL: jdbc:oracle:thin:@stahs08.us.oracle.com:1521:ORCL (enter
the correct connection URL)
JDBC Driver: oracle.jdbc.driver.OracleDriver
Username: CUSTDATA (replace with the username used to access
the RDBMS)
Password: PASSWORD (replace with the password used to access
the RDBMS)
Location: jdbc/RDBMSUserDataSource
Transactional Loc: jdbc/xa/RDBMSUserDataSource
EJB Location: jdbc/RDBMSUserDataSource
Note:
The database connection information must be updated to reflect your deployment configuration; refer to the Oracle Application Server and Oracle JDBC documentation for more information.Apply the changes.
Take these steps to configure Oracle Identity Federation with eTrust SiteMinder to use an RDBMS User Data Store:
Log into the Oracle Identity Federation administration console and navigate to IdM Data Stores - > User Data Store.
Select eTrust SiteMinder from the Active Repository list.
Select 'Relational Database' as the back-end data store and enter the appropriate values, as explained in this table:
| Field | Example | Comment |
|---|---|---|
| JNDI Name | jdbc/RDBMSUserDataSource | Must match the EJB Location entered in the Oracle Enterprise Manager console |
| User Name | CUSTDATA | Replace with the username used to access the RDBMS |
| Password | PASSWORD | Replace with the password used to access the RDBMS |
| Login Table | EMPLOYEES | Replace with the name of the RDBMS table containing the user records |
| Login ID Column | EMPLOYEE_ID | Replace with the column name containing the user identifiers |
| Login Pwd Column | Empty | This attribute is not used when configured with eTrust SiteMinder Server for authentication. |
| Password Digest Algorithm | None. | A password digest algorithm is not used in this deployment. |
| User Desc. Attribute | EMPLOYEE_ID | Replace with the value used in the Login ID Column field. This field must be a column containing a user identifier that will be used to create the federation records: this attribute provides a way to have a human-readable attribute set on the user federation record. This field is useful when the main user identifier is not human-readable. In this case, since the main user identifier is the username, setting that field to the Login ID Column value is sufficient. |
Click Apply to save the changes.
Enter the connection information to the eTrust SiteMinder policy server:
See Also:
"Edit User Data Store"Host - This is the host where the policy server is installed.
Authorization Port - This is the policy server port used for authentication requests. The default value is 44442.
Authentication Port - This is the policy server port used for authentication requests. The default value is 44443.
Accounting Port - This is the policy server port used for accounting requests. The default value is 44441.
Max Connections - This is the maximum number of agent connections to the policy server.
Min Connections - This is the minimum number of agent connections to the policy server.
Step Connections - This is the number of connections the agent can open to the policy server at one time.
Timeout - This is the time, in seconds, that the agent will wait for a response from the policy server before it returns a failure.
Enter the following information in the eTrust SiteMinder Agent Configuration section:
Enter the Agent Name and the Agent Secret of an existing eTrust SiteMinder Web Agent. That agent's credentials are used at startup time to verify that the Oracle Identity Federation SMBridgeAgent exists and is correctly registered.
Enter the Cookie domain used by the eTrust SiteMinder policy server. Oracle Identity Federation uses this value when locally authenticating a user and setting the SMSESSION Cookie.
Enter the Oracle Identity Federation SMBridgeAgent password. This password must match the password of the eTrust SiteMinder Agent identified as SMBridgeAgent on the Policy Server.
Enter the following information in the Automatic Policy Creation section:
Admin ID - This is the username of an eTrust SiteMinder account to access the Policy server.
Admin Password - This is the password to access the Policy server.
Domain Name - This is the domain in which the policy objects are contained.
User Directory - This is the user directory for the domain.
This information is used at startup time to verify that the necessary eTrust SiteMinder policy objects required by Oracle Identity Federation are present in the eTrust SiteMinder policy server.
If the policies are already created and correctly configured, the credentials specified in this section can reference an eTrust SiteMinder account with only read privileges.
Click Apply.
Since Oracle Identity Federation was not designed to use a User Data Store different from the eTrust SiteMinder server, the following configuration steps are required to retrieve the correct user identifier during in a Single Sign-On flow:
Log in to the Oracle Identity Federation administration console and navigate to IdM Data Stores - > User Data Store.
Select LDAP Directory as the back-end data store for the eTrust SiteMinder server.
In the User ID Attribute field, enter the attribute used in the LDAP user record containing the user identifier. For common LDAP servers, it should be set to uid.
Click Apply.
Navigate to IdM Data Stores - > User Data Store.
Select Relational Database as the back end data store.
Click Apply.
Restart OC4J_FED.
eTrust SiteMinder Web Agents need to be configured to do the following:
The Web Agent needs to specify the domain on the SMSESSION cookie, so that Oracle Identity Federation will be able to consume the SMSESSION cookie.
The Web Agent needs to accept the SMSESSION cookies set by Oracle Identity Federation, in the case where the Oracle Identity Federation eTrust SiteMinder Agent will authenticate the user.
Before changing the Web Agent configuration, take these steps to determine whether the agent is using local configuration files:
Identify the eTrust SiteMinder Web Agent responsible for setting the SMSESSION cookie: this is the agent authenticating the user.
Go to the eTrust SiteMinder Administration Console.
Go to the Web Agent Config Objects section.
Select the entry for the eTrust SiteMinder Web Agent you identified in the first step.
Find the AllowLocalConfig parameter in the list.
Subsequent action depends on the value of this parameter.
If the AllowLocalConfig parameter value is "Yes", then you will need to modify the WebAgent.conf file of the eTrust SiteMinder Web Agent.
This file is typically located on the machine where the Web Agent is installed, in the directory where the eTrust SiteMinder Web Agent binaries and configuration files were installed: $HOME\Netegrity\SiteMinder Web Agent\Bin\$HTTP_SERVER_NAME\WebAgent.conf, with $HOME being the parent directory of the eTrust SiteMinder Web Agent installation directory (for example, c:\Program Files), and $HTTP_SERVER_NAME being the directory name that corresponds to the HTTP Web Server integrated with the Web Agent (for example, IIS if eTrust SiteMinder Web Agent is integrated with Microsoft IIS).
In this WebAgent.conf file, add the following parameter:
CookieDomain=".domain.com"
and replace.domain.com with the domain on which you are deployed.
Save the changes and restart the HTTP Server to force the Web Agent to reload its configuration.
If the AllowLocalConfig parameter value is "No", then you will need to take these steps to modify the Web Agent Configuration object on the eTrust SiteMinder Policy Server:
Go to the eTrust SiteMinder Web Agent entry.
Go to the Web Agent Config Objects section.
Locate the CookieDomain parameter, and set its value to the domain on which you are deployed.
Save the changes and restart the HTTP Server to force the Web Agent to reload its configuration.
Following steps similar to those you used to determine whether the Web Agent uses local configuration files (in the section titled "Update the Cookie Domain"), update the AcceptTPCookie property to "Yes" to allow the eTrust SiteMinder Web Agent to consume SMSESSION cookies set by Oracle Identity Federation.
This property will be required if the user first authenticates at the Oracle Identity Federation server.
This section lists, by way of example, the policy objects from an eTrust SiteMinder Policy Server after post-initialization of the Oracle Identity Federation/eTrust SiteMinder connector.
#! SiteMinder Version 5.5
# Export Flags: Encrypted.
objectclass: Scheme
Oid: 0d-9a73cf80-225b-4267-8788-c9d1dd6f49b1
Name: OracleFederation_Login
Desc: Automatically created by SHAREid. Do not modify.
Level: 1
Lib: smauthdir
Param:
Secret: {RC2}XCoISknMgVRXLjoLd/Fzkg==
IsTemplate: false
IsUsedbyAdmin: false
Type: 1
AllowSaveCreds: false
IsRadius: false
IgnorePwCheck: false
objectclass: Scheme
Oid: 0d-afefd918-eb06-4322-bb54-5095c2a62976
Name: OracleFederation_LoginNoPwd
Desc: Automatically created by SHAREid. Do not modify.
Level: 1
Lib: smanapi
Param:
Secret: {RC2}zlnvNoQWQLsgkpm5lDGtnA==
IsTemplate: false
IsUsedbyAdmin: false
Type: 15
AllowSaveCreds: false
IsRadius: false
IgnorePwCheck: false
objectclass: Agent
Oid: 01-989a3b03-5f9a-4714-9e4c-8ce2e08914af
Name: oif_agent
Desc: oif_agent
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
RealmHintAttrId: 0
objectclass: TrustedHost
Oid: 24-e49e94f7-f914-49be-92ed-a10685759ad2
Name: oif_agent
Desc: oif_agent
IpAddr: 140.87.155.127
Secret: {RC2}4eRzjIbX82w6r2Ke+ph3KA==
Is4xHost: true
objectclass: Agent
Oid: 01-fe46c0bd-2802-4a3e-8dcf-a68a4f3eb40c
Name: smbridgeagent.oif1.staqk10vm4.us.oracle.com
Desc: Automatically created by SHAREid. Do not modify.
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
RealmHintAttrId: 0
objectclass: TrustedHost
Oid: 24-ca92dc34-8ebc-4c83-9bbd-001c33542fb3
Name: smbridgeagent.oif1.staqk10vm4.us.oracle.com
Desc:
IpAddr: 140.87.155.130
Secret: {RC2}z3gdtk5parnuWkqt73fGPA==
Is4xHost: true
objectclass: AgentGroup
Oid: 02-70eb00c8-30f4-4f9e-8e46-722014a42e02
Name: OracleFederation
Desc: Automatically created by SHAREid. Do not modify.
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Agents: 01-fe46c0bd-2802-4a3e-8dcf-a68a4f3eb40c
objectclass: Domain
Oid: 03-1c7ac22e-6646-4c61-8f2f-6261a0ef3a92
Name: FederationWebServicesDomain
Desc:
Realms: 06-a0cf82a7-d831-453d-ac9e-8ed814f90369
UserDirectories: 0e-08c6cadb-e30b-4e06-9e2e-b3d7a866fab8
Rules: 0b-ebe4b3ce-5a34-4a64-b67b-d1e64dee414d, 0b-3d48caac-a7d5-4cf7-8722-ea9ed257fa42, 0b-7f5c5171-8af3-48b0-897c-89d02ac15d43
RuleGroups:
Responses:
ResponseGroups:
Policies: 04-3d844415-ee88-46f0-b646-cfbc57e248b8, 04-6d11edc8-b6f4-4522-a956-b3ad263705fb, 04-70d60545-5316-49c3-ac96-ae5c75b7efe8
Admins:
Variables: 1d-dad4d124-7518-4b67-b72c-b4ef76622eb3, 1d-98031368-1b9d-4d40-b572-91cef289f497
ActiveExprs: 1f-ec5691c8-b45c-4ed7-8d69-95e1caa6c8ef, 1f-bcf186ea-cd60-4e9c-96c3-5d3076090ce1
IsAffiliate: false
IMSEnvs:
Mode: 0
objectclass: Realm
Oid: 06-09c376b0-44f4-4aa1-b076-52fe1ca05309
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_Login
Desc: Automatically created by SHAREid. Do not modify.
ResourceFilter: /OracleFederation/Login
Agent: 02-70eb00c8-30f4-4f9e-8e46-722014a42e02
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Scheme: 0d-9a73cf80-225b-4267-8788-c9d1dd6f49b1
ProcessAuthEvents: true
ProcessAzEvents: true
ProtectAll: true
SelfRegOid: 00-
AzUserDirOid: 00-
MaxTimeout: 0
IdleTimeout: 0
ParentRealmOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
SyncAudit: false
Type: 0
SessionType: 0
SessionDrift: -1
objectclass: Realm
Oid: 06-e076704c-2d8e-4c10-83f0-6d67e2c38163
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_LoginNoPwd
Desc: Automatically created by SHAREid. Do not modify.
ResourceFilter: /OracleFederation/LoginNoPwd
Agent: 02-70eb00c8-30f4-4f9e-8e46-722014a42e02
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Scheme: 0d-afefd918-eb06-4322-bb54-5095c2a62976
ProcessAuthEvents: true
ProcessAzEvents: true
ProtectAll: true
SelfRegOid: 00-
AzUserDirOid: 00-
MaxTimeout: 0
IdleTimeout: 0
ParentRealmOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
SyncAudit: false
Type: 0
SessionType: 0
SessionDrift: -1
objectclass: Rule
Oid: 0b-0bac8120-dd43-45a4-badd-5f56df272c2a
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_Login
Desc: Automatically created by SHAREid. Do not modify.
Realm: 06-09c376b0-44f4-4aa1-b076-52fe1ca05309
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Action: Get
Resource: *
Time: 00000000-00000000-7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
AllowAccess: true
RegularExpression: false
IsEnabled: true
ActiveExpr: 00-
Variables:
objectclass: Response
Oid: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_UserAttributes
Desc: Automatically created by SHAREid. Do not modify.
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Attributes: 08-8d8cf013-e93f-4a06-83b5-7eb44432bfb7, 08-fef77ff7-038d-4a94-840a-c562f137da5d, 08-8cb3d975-56b1-4b0d-a742-a1c044624b28
AccessAccept: false
AccessReject: false
AccessChallenge: false
Type: 0
objectclass: ResponseAttr
Oid: 08-8d8cf013-e93f-4a06-83b5-7eb44432bfb7
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Response: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
AgentTypeAttr: 11-8d78bb90-ae15-11d1-9cdd-006008aac24b
Value: uid=<%userattr="uid"%>
TTL: 0
Flags: 0
ActiveExpr: 00-
objectclass: ResponseAttr
Oid: 08-fef77ff7-038d-4a94-840a-c562f137da5d
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Response: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
AgentTypeAttr: 11-8d78bb90-ae15-11d1-9cdd-006008aac24b
Value: mail=<%userattr="mail"%>
TTL: 0
Flags: 0
ActiveExpr: 00-
objectclass: ResponseAttr
Oid: 08-8cb3d975-56b1-4b0d-a742-a1c044624b28
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Response: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
AgentTypeAttr: 11-8d78bb90-ae15-11d1-9cdd-006008aac24b
Value: genUserID=<%userattr="genUserID"%>
TTL: 0
Flags: 0
ActiveExpr: 00-
objectclass: PolicyLink
Oid: 05-88999535-dc1e-46c0-8420-b22ae3feb56f
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Rule: 0b-75967ff0-bffd-4410-acc8-6cbe3e65c68f
Response: 00-
Policy: 04-98e5b0bc-f051-4447-8b99-08b1d7454115
objectclass: PolicyLink
Oid: 05-8c49d99a-c459-4b48-bd32-e6f755d3cd34
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Rule: 0b-2259776d-e839-4eb4-9b0e-97adf95ae19a
Response: 00-
Policy: 04-98e5b0bc-f051-4447-8b99-08b1d7454115
objectclass: UserPolicy
Oid: 0f-d1c1fe0a-526e-4471-93c3-abd40109eb2d
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
FilterPath: o=company,c=us
FilterClass: organization
PolicyResolution: 5
PolicyFlags: 0
UserDirectory: 0e-0aec4e86-469e-400f-ab82-2d75685ce40b
Policy: 04-98e5b0bc-f051-4447-8b99-08b1d7454115
objectclass: Policy
Oid: 04-aa1d7959-82b9-4dca-9737-ff89f153d10e
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_UserAttributes
Desc: Automatically created by SHAREid. Do not modify.
Time: 00000000-00000000-7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
PolicyLinks: 05-b09b8003-d82c-4586-8132-9c9bf2a40874
UserPolicies: 0f-c1147a2a-a47b-455d-a52f-19f8cf401961
AllowAccess: true
IsEnabled: true
IPAddress:
Type: 0
ActiveExpr: 00-
UserActiveExpr: 00-
objectclass: PolicyLink
Oid: 05-b09b8003-d82c-4586-8132-9c9bf2a40874
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Rule: 0b-0bac8120-dd43-45a4-badd-5f56df272c2a
Response: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
Policy: 04-aa1d7959-82b9-4dca-9737-ff89f153d10e
objectclass: UserPolicy
Oid: 0f-c1147a2a-a47b-455d-a52f-19f8cf401961
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
FilterPath: (genuserid=*)
FilterClass: User Attribute
PolicyResolution: 3
PolicyFlags: 0
UserDirectory: 0e-0aec4e86-469e-400f-ab82-2d75685ce40b
Policy: 04-aa1d7959-82b9-4dca-9737-ff89f153d10e
This section describes how to integrate the Sun Java System Web Server with Oracle Identity Federation in the following configuration:
One Oracle Identity Federation instance configured as a Service Provider (SP) with an Oracle Access Manager back end, using any directory server; and
A second Oracle Identity Federation instance configured as an Identity Provider (IdP), with any directory server or database as the back end.
This section contains the following topics:
Configuring Oracle Identity Federation Without a Web Proxy Server
Configuring Oracle Identity Federation Behind a Web Proxy Server
Integrating Oracle Identity Federation with OracleAS Single Sign-On
(This section explains how to implement an Oracle Application Server Single Sign-On back end.)
When using a proxy in front of Oracle Identity Federation, the host name and port number of the proxy server instance are used, respectively, as the host and port of the Oracle Identity Federation fedadmin administration console. Since the proxy hides only the fedadmin console, it is necessary to create a second instance of Sun Java System Web Server with a reverse proxy plugin to hide the application server console as well.
This configuration requires two separate procedures:
Configuring the Identity Provider
Configuring the Service Provider
Configuring the Identity Provider
Take the following steps to configure the Identity Provider (IdP):
Install an instance of Oracle Identity Federation.
For installation details, see Chapter 3, Installing Oracle Identity Federation, in the Oracle Identity Federation Administrator's Guide.
Log in to the administration console at:
http://IdPhost:port/fedadmin
Go to Server Configuration -> General -> Server properties
Enter the Server Name as the fully qualified hostname.
The Server Port and SOAP Port are the same as the fedadmin port.
Do not modify any other information.
Go to Server Properties -> Service Provider -> Global Settings.
Enter the Provider URL as http://fully-qualified-host:port/fed/sp.
Go to Server Properties -> Identity Provider -> Global Settings.
Enter the Provider URL as http://fully-qualified-host:port/fed/idp
Enter the Common Domain Name in the format:
.mycompany.com
Go to IDM Data Store -> User Data Store.
Select the active repository.
Enter the following repository parameters:
| Field | Value |
|---|---|
| Connection URL | If LDAP, provide the URL as ldap://host:port |
| Bind DN | cn=directory manager and provide password in the password field |
| User ID Attribute | Login user id |
| User Description Attribute | Same as User ID Attribute |
| Person Object Class | As appropriate, for example inetorgperson |
| Base DN | Same as DN of searchbase |
Accept the default values for the remaining fields.
On the same page, go to the Federation Data Store and choose the active repository.
Enter the following repository parameters:
| Field | Value |
|---|---|
| Connection URL | If LDAP, provide the URL as ldap://host:port |
| Bind DN | cn=directory manager and provide password in the password field |
| User Federation Record Context | Same as for searchbase |
Accept the default values for the remaining fields.
To collect the metadata, in the browser enter a URL of the form:
http://hostname/fed/idp/metadatav11, or
http://hostname/fed/idp/metadatav12, or
http://hostname/fed/idp/metadatav20
Save the metadata to a file.
Configuring the Service Provider
Take the following steps to configure the Service Provider (SP):
Install Oracle Access Manager.
Install Oracle Identity Federation. Log in to the administration console at:
http://host:port/fedadmin
Go to Server Configuration -> General -> Server properties.
Enter the Server Name as the fully qualified hostname.
For example:
host.mycompany.com:port
The Server Port and SOAP Port are the same as the fedadmin port.
Do not modify any other information.
Go to Server Properties -> Service Provider -> Global Settings.
Enter the Provider URL as http://fully-qualified-host:port/fed/sp.
Go to Server Properties -> Identity Provider -> Global Settings.
Enter the Provider URL as http://fully-qualified-IdPhost:port/fed/idp
Enter the Common Domain Name in the format:
.mycompany.com
Install the Oracle Access Manager Access Server SDK at OIF_Install_Dir/fed/shareid. The Access Server SDK is installed at OIF_Install_Dir/fed/shareid/AccessServerSDK.
Use Oracle Access Manager to configure an AccessGate instance for Oracle Identity Federation.
Note:
The Access management Service should be ON for the AccessGate Configuration.At the Access System Console, create a host identifier with name Fed HostID in the format:
fully-qualified-SPhost:port
Create a policy domain to protect any test resource using the Fed SSO - SAML 2.0/Liberty 1.x authentication Scheme.
In the Oracle Identity Federation administration console, go to IDM Data Store -> User Data Store.
Select Oracle Access Manager as the active repository.
Enter the following repository parameters:
| Field | Value |
|---|---|
| Connection URL | If LDAP, provide the URL as ldap://host:port |
| Bind DN | cn=directory manager and provide password in the password field |
| User ID Attribute | Login user id |
| User Description Attribute | Same as User ID Attribute |
| Person Object Class | As appropriate, for example inetorgperson |
| Base DN | Same as DN of searchbase |
Accept the default values for the remaining fields.
For the Oracle Access Manager configuration parameters, provide following information:
| Field | Value |
|---|---|
| Master Admin Login ID | admin userid |
| Master Admin Password | admin user password |
| Authorization result for unprotected resources | Allow |
| Oracle Access Manager Cookie Domain | Fully qualified host name |
| Basic Authentication Scheme Name | Oracle Access and Identity Basic Over LDAP (for Oracle Access Manager 10.1.4 and above) or Basic Over LDAP (for 7.0.4). |
Click Apply.
On the same page, go to Federation Data Store.
Select the active repository.
Enter the following repository parameters:
| Field | Value |
|---|---|
| Connection URL | If LDAP, provide the URL as ldap://host:port |
| Bind DN | cn=directory manager and provide password in the password field |
| User Federation Record Context | cn=fed, searchbase |
Accept the default values for the remaining fields.
Go to Server Configuration -> Circle of Trust.
From the Add Trusted Provider page, upload the metadata that you collected for IdP and refresh the server.
Once the IdP appears in the list of Identity Providers, go to the main menu, go to Identity Federation, and make sure that the IdP URL shows up in the Identity Providers list.
Go to Server Configuration -> Service Provider -> Global Settings.
In the drop-down list for the Default SSO Identity Provider, select the URL of the IdP provider.
Save the changes and refresh the server.
To collect the metadata, in the browser enter a URL of the form:
http://hostname/fed/sp/metadatav11, or
http://hostname/fed/sp/metadatav12, or
http://hostname/fed/sp/metadatav20
Save the metadata to a file.
Upload this metadata to the IdP.
Follow the procedure defined in "Configuring Oracle Identity Federation Without a Web Proxy Server" , with these modifications:
Change the configuration URLs to their respective proxy server URLs.
In the Oracle Identity Federation administration console, go to SAML 1.x/WS-Fed - > Domains - > MyDomain and update the SAML 1.x/WS-Fed configuration URLs:
Error URL
Transfer URL
Responder URL
SourceID (blank to regenerate for new ResponderURL)
Identity Realm Secure Token Service (STS) URL
Receiver URL
Resource Realm STS URL
See "Configuring SAML 1.x and WS-Federation Properties" for information about these URLs.
Collect the metadata using the proxy URLs, not actual URLs, then upload the metadata.
At the Access System Console, create a host identifier in the format:
proxy-host:port
and change the challenge redirect of the authentication scheme to proxy-host:port.
To integrate Oracle Identity Federation with an Oracle Single Sign-On back end, take these additional steps:
Update the OracleAS Single Sign-On partner application:
Go to the Oracle Single Sign-On administration console (http://osso_host:osso_port/pls/orasso).
Click Single Sign-On Administration.
Click Administer Partner Applications.
Choose the partner application referencing the Oracle Identity Federation server, and edit the application configuration.
Replace the http(s), hostname and port number by the proxy's values for Home URL, Success URL, and Logout URL.
Click OK.
Update the policy.properties file:
Open the ORACLE_HOME/sso/conf/policy.properties file in the OracleAS Single Sign-On deployment.
Replace the http(s), hostname and port number by the proxy's value for the SASSOAuthnUrl and SASSOLogoutUrl entries.
Save and close the file.
Restart the OC4J_SECURITY instance of the OracleAS Single Sign-On deployment by using the command:
opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
This section provides samples of the obj.conf and magnus.conf configuration files.
Sample obj.conf File
<Object name="default"> AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true" NameTrans fn="assign-name" from="/*" name="serverexample" NameTrans fn="ntrans-j2ee" name="j2ee" NameTrans fn=pfx2dir from=/mc-icons dir="/home/panacea/SunOne6.1/ns-icons" name="es-internal" NameTrans fn=document-root root="$docroot" PathCheck fn=unix-uri-clean PathCheck fn="check-acl" acl="default" PathCheck fn=find-pathinfo PathCheck fn=find-index index-names="index.html,home.html,index.jsp" ObjectType fn=type-by-extension ObjectType fn=force-type type=text/plain Service method=(GET|HEAD) type=magnus-internal/imagemap fn=imagemap Service method=(GET|HEAD) type=magnus-internal/directory fn=index-common Service method=(GET|HEAD|POST) type=*~magnus-internal/* fn=send-file Service method=TRACE fn=service-trace Error fn="error-j2ee" AddLog fn=flex-log name="access" </Object> <Object name="j2ee"> Service fn="service-j2ee" method="*" </Object> <Object name="cgi"> ObjectType fn=force-type type=magnus-internal/cgi Service fn=send-cgi user="$user" group="$group" chroot="$chroot" dir="$dir" nice="$nice" </Object> <Object name="es-internal"> PathCheck fn="check-acl" acl="es-internal" </Object> <Object name="send-compressed"> PathCheck fn="find-compressed" </Object> <Object name="compress-on-demand"> Output fn="insert-filter" filter="http-compression" </Object> # Execute these instructions for any resource with the assigned name # "server.example.com" <Object name="serverexample"> # Proxy the requested resource to the URL # "http://server.example.com:8080" Service fn="service-passthrough" servers="http://flagstaff.persistent.co.in:7777" </Object>
Sample magnus.conf File
# # The NetsiteRoot, ServerName, and ServerID directives are DEPRECATED. # They will not be supported in future releases of the Web Server. NetsiteRoot /home/panacea/SunOne6.1 ServerName calgary ServerID https-oif_idp_flagstaff # RqThrottle 128 DNS off Security off PidLog /home/panacea/SunOne6.1/https-oif_idp_flagstaff/logs/pid User panacea StackSize 131072 TempDir /tmp/https-oif_idp_flagstaff-65cd125c Init fn=flex-init access="$accesslog" format.access="%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] \"%Req->reqpb.clf-request%\" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%" Init fn="load-modules" shlib="/home/panacea/SunOne6.1/bin/https/lib/libj2eeplugin.so" shlib_flags="(global|now)" Init fn="load-modules" shlib="/home/panacea/SunOne6.1/bin/https/passthrough/plugins/passthrough /libpassthrough.so"
This section describes how to configure Oracle Identity Federation to use IBM Tivoli Directory Server (IBM TDS) 6.0 in the back end, as either a federation data store or a user data store. Topics include:
Configuring IBM Tivoli Directory Server as the Federation Data Store for IDP or SP
Configuring IBM Tivoli Directory Server as the User Data Store for an IdP
Check that the following prerequisites are met before setting up the IBM TDS data store:
Install Oracle Identity Federation.
Install and configure IBM TDS v6.0.
Externally load the federation schema into IBM TDS to create federation records; for this LDAP schema update, use the $ORACLE_HOME/setup/ldap/userFedSchemaTivoli.ldif file.
Refer to "Federation Data Store", in the discussion titled "A Note About LDAP Schema" for details on how to configure the LDAP schema.
In the Oracle Identity Federation Administration Console, navigate to IdM Data Stores -> Edit Federation Data Store.
See Also:
"Edit Federation Data Store" for details about field configuration.Select LDAP Directory for the active repository.
Provide these repository parameters:
Connection URL(s) - This is the Connection URL; enter a space-delimited list of IBM Tivoli Directory Server URLs with hostname and port.
Bind DN - This is the DN used by the Oracle Identity Federation server to connect to the IBM Tivoli Directory Server.
Password - Enter the administrator account password to use to connect to the LDAP server.
User Federation Record Context - Enter the node under which all federation records for this Oracle Identity Federation server will be stored.
LDAP Container Object Class - Enter the type of User Federation Record Context that Oracle Identity Federation should use when creating the LDAP container. For example, for the IBM Tivoli Directory Server this field can be left empty.
Note:
The User Federation Record Context must be compatible with the LDAP Container Object Class, as explained in "Edit Federation Data Store".Unique Federation ID Attribute - Enter the LDAP attribute to be used to uniquely identify a federation record. For example, for IBM Tivoli Directory Server this field can be left empty.
Maximum Connections - Enter the maximum number of concurrent connections that can be made by Oracle Identity Federation to the IBM Tivoli Directory Server.
Connection Wait Timeout (secs) - Enter the maximum number in seconds to wait until a connection is available, when the maximum number of connections opened by Oracle Identity Federation to the IBM Tivoli Directory Server has been reached.
In the Oracle Identity Federation Administration Console, navigate to IdM Data Stores -> Edit User Data Store.
See Also:
"Edit User Data Store" for details about field configuration.Select LDAP Directory from the active repository.
Provide these repository parameters:
Connection URL(s): Enter the Connection URL as a space-delimited list of IBM Tivoli Directory Server URLs with hostname and port.
Bind DN: This is the DN used by the Oracle Identity Federation server to connect to IBM Tivoli Directory Server.
Password: Enter the administrator account password to use to connect to the data store.
User ID Attribute: Enter the attribute name to use to map users during lookups or authentication procedures. For example, for theIBM Tivoli Directory Server this field can be set to uid.
User Description Attribute: This field references the user attribute to use as a human readable federation owner identifier. This information will be stored in the federation record. For example, for the IBM Tivoli Directory Server this field can be set to uid.
Person Object Class: Enter the LDAP object class representing a user in the IBM Tivoli Directory Server. For example, for the IBM Tivoli Directory Server this field can be set to inetOrgPerson.
Base DN: Enter the node under which the IBM Tivoli Directory Server user search will be performed. For example: dc=us,dc=oracle,dc=com.
Connection Wait Timeout (secs): Enter the maximum number in seconds to wait until a connection is available, when the maximum number of concurrent connections made by Oracle Identity Federation to the IBM Tivoli Directory Server has been reached.
Oracle Identity Federation provides cross-domain Single Sign-On using standard protocols such as SAML, Liberty, and WS-Federation.
Out of the box, Oracle Identity Federation integrates with several Identity and Access Management (IAM) products, including:
Oracle AS Single Sign-On
Oracle Access Manager
CA eTrust SiteMinder
Oracle Identity Federation also provides a framework for developers to integrate custom or third-party Identity and Access Management solutions. This section explains the components of this framework, and shows you how to configure and integrate a custom IAM solution into the framework.
Note:
Oracle strongly discourages users from deploying any applications on the OC4J_FED J2EE container instance other than the custom integration and authentication described in this section, because doing so introduces potential security risks. Extraneous applications deployed in the OC4J_FED container can potentially affect the security of the federation server by allowing rogue software to change the behavior of the server flows.This section includes the following topics related to custom engine implementation:
At runtime, Oracle Identity Federation interacts with two types of external modules: a user data store, and an Identity and Access Management system.
Oracle Identity Federation works with the user data store to:
locate a user after local authentication
locate a user after processing an incoming SAML Assertion
retrieve attributes for a specific user
The Identity and Access Management (IAM) system provides access control for protected resources. Oracle Identity Federation, as the federation server, interacts with IAM to:
authenticate a user when the server needs to obtain a user's local identity. This operation might occur when the server acts as an IdP, or when the server, as an SP, needs to authenticate the user during initial account linking/federation creation.
create an authenticated session for a specific user when the server processes an incoming SAML Assertion and asserts the user's identity to the IAM system
process logout flows; in this case, the federation server invokes IAM capabilities to log the user out of the system
Figure 4-1 depicts the different external and internal modules of an Oracle Identity Federation deployment, and how they interact at runtime:
For the sake of this discussion, the Oracle Identity Federation server is depicted as three internal modules:
the Identity Federation Engine, which is responsible for creating and processing SAML messages such as AuthnRequest, Assertion, and Logout messages.
This module:
works with the user data store when processing SAML messages;
interacts with the Authentication Engine when it is necessary for a user to be locally identified; and
interacts with the SP Integration Engine when the user is redirected to the IAM component after processing an Assertion.
the Authentication Engine, which is responsible for processing requests from the Federation Engine to authenticate users. This module interacts with the IAM component and the user data store to authenticate the user and retrieve the unique identifier Oracle Identity Federation uses to reference the user.
This module can be invoked in either IdP or SP mode when local authentication is required.
After authenticating the user, the Authentication Engine sends the authentication information, such as the user's identifier, the time of authentication, and other data to the Federation Engine.
After successfully processing an incoming SAML assertion and locating the user referenced by the assertion, the Federation Engine instructs the SP Integration Engine to create an authenticated session for that user in the IAM domain. It passes the necessary information (user's identifier, authentication time, and so on) to the SP Integration Engine, which interacts with the IAM server to create the session.
The Authentication Engine included with Oracle Identity Federation contains a servlet to process requests from server to authenticate a user, and several internal plug-ins that allow it to interact with the various IAM servers supported out of the box (see the introduction to this discussion ).
Here is a step-by-step description of how the Authentication Engine interacts with the other federation server components in a typical user flow:
The user accesses Oracle Identity Federation for an SSO operation (in either SP or IdP mode).
An internal process in the server determines that the user needs to be identified.
The federation server redirects the user to itself in order to drop the existing query String parameters and replace them with Oracle Identity Federation query Strings. A typical new query String includes these parameters:
doneURL - The relative URL where the user needs to be forwarded back once the Authentication Engine identifies the user, when the getUsrSess parameter value is not true.
authnMech - The authentication mechanism requested by the federation server to use to authenticate the user.
refID - An identifier referencing data in the federation server. When present, this parameter must be passed back to Oracle Identity Federation when the Authentication Engine forwards the user.
getUsrSess - A boolean parameter indicating whether the user should be redirected to the WS-Fed/SAML 1.x protocol engines instead of to the doneURL parameter.
The Federation Engine internally forwards the user's request to the /sso/authn URL (the context is /sso, and the forward URL is /authn). On the HttpServletRequest, a String attribute called oracle.security.sso.sasso.authn.dyna_mode is set to the value idp to indicate that it is requesting a user authentication.
The Authentication Engine processes the incoming request. It has access to the following information:
doneURL, authnMech, refID , and getUsrSess as query parameters
oracle.security.sso.sasso.authn.dyna_mode as an HttpServletRequest attribute
The Authentication Engine interacts with the IAM component and may challenge the user for credentials. After successful authentication, it may set a cookie (for example, to maintain the authenticated session with the IAM server and/or the target application).
If the getUsrSess parameter is missing or set to false, the Authentication Engine forwards the user back to the Liberty 1.x / SAML 2.0 Federation Engine at the doneURL in the federation context (the context is /fed and the forward URL is the doneURL query parameter received earlier).
If the getUsrSess parameter value is true, the Authentication Engine forwards the user back to the WS-Fed / SAML 1.x Federation Engine into the /shareid context, at the /saml/ObSAMLLoginService relative URL.
The Authentication Engine sets these HttpServletRequest attributes:
A String attribute, oracle.security.sso.sasso.uid, containing the user's identifier. The Federation Engine uses this identifier to locate the user based on the user record attribute set in the Oracle Identity Federation Administration Console (specifically, the User ID field on the User Data Store page).
A String attribute, oracle.security.sso.sasso.refID, containing the refID query parameter value sent earlier.
A String attribute, oracle.security.sso.sasso.authnMech, containing the oracle authentication mechanism identifier that references the method used to authenticate the user. At this time, the value can only be set to oracle:fed:authentication:password-protected.
A date attribute, oracle.security.sso.sasso.authnInst, containing the instant when the user was authenticated.
Note:
This attribute contains an object of class
java.util.Date.Oracle Identity Federation:
processes the incoming request
retrieves the data embedded as attributes in the HttpServletRequest
locates the user in the user data store
creates a session for the user
sets a cookie, and
resumes the SSO operation.
The SP Integration Engine included with Oracle Identity Federation consists of a servlet that processes requests from the server to create a user authenticated session at the IAM server. The engine includes several internal plug-ins that allow it to interact with different IAM Servers.
Here is a step-by-step description of how the SP Integration Engine interacts with the other federation server components in a typical user flow:
The user triggers a Federation SSO operation with a remote IdP. The SSO is triggered either at the IdP (IdP-initiated SSO), or at the Oracle Identity Federation SP, by requesting the /fed/sp/initiatesso URL with these query parameters:
providerid - the IdP's provider ID [REQUIRED]
returnurl - the URL to redirect the user to after successful Federation SSO [OPTIONAL]
Note:
Refer to "SP-initiated SSO with Liberty 1.x/SAML 2.0" for a complete description of these parameters.The IdP redirects the user, with an assertion, to the federation server acting as an SP.
The server processes the assertion and locates the user in the user data store. The user is now authenticated at the federation server.
The federation engine internally forwards the user to the /sso/authn URL and passes the following data as HttpServletRequest attributes:
the user's Identifier
the time of authentication
the expiration time of the authenticated session. This is the lesser of the Oracle Identity Federation Session Timeout and the session expiration sent by the IdP in the assertion
the URL to which to redirect the user
The SP Integration Engine interacts with the IAM server to create an authenticated session for the user. The session is based on the data received from Oracle Identity Federation.
The SP Integration Engine redirects the user to the final target URL.
Oracle Identity Federation's design is consistent with certain requirements regarding authentication operations and SP integration (where a user session is created at the IAM server). Consequently, you must meet the following requirements when implementing a custom authentication engine or an SP Integration Engine:
The Authentication Engine, the SP Integration Engine, the Identity Federation Engine and the IAM server must use the same user data store as the user repository. This store contains the user data used to look up and authenticate users.
The Authentication Engine and the SP Integration Engine must include a Java Servlet /JSP.
The data exchanges between OIF and the Authentication/SP Integration Engines are done via internal HTTP request forwarding. This is actually an internal API call between the modules that relies on the J2EE servlet framework via the HTTP protocol.
A logout service needs to be implemented and made available to the Authentication Engine and/or the SP Integration Engine. This logout service must be published as Servlet/JSP.
If both a customized Authentication Engine and an SP Integration Engine are implemented with Oracle Identity Federation, you must configure the user data store for LDAP or RDBMS in Standalone mode. This is necessary so that Oracle Identity Federation does not attempt to interact with an IAM Server (Oracle SSO, Oracle Access Manager or CA SiteMinder), for example at initialization time.
This section explains how to plan, develop, and implement a custom authentication engine.
Creating a customized authentication engine involves:
creating a service that will process incoming requests from Oracle Identity Federation
implementing a module to authenticate a user
creating a service that forwards the user to the federation server with the required information
deciding whether or not the Authentication Engine will set a cookie after authenticating a user. If yes, the authentication module must be integrated into the logout process (see "Logout")
packaging the services and module into a web application, and deploying the application to the OC4J_FED instance of the Oracle Application Server where Oracle Identity Federation is running
modifying Oracle Identity Federation configuration files to reference the new Authentication Engine.
Note:
This step requires an OC4J_FED restart.ensuring that the user repository used by the Authentication Engine is the same as the user data store configured in the Oracle Identity Federation Administration Console and used by the federation server
Several aspects of module development are explained here.
URLs
Communication between the Federation Engine and the Authentication Engine occurs through internal servlet forwards that are equivalent to API calls. These forwards use the following J2EE API:
ServletContext.getContext(String contextPath)
.getRequestDispatcher(String relativePath)
.forward(HttpServletRequest request,
HttpServletResponse response)
where:
contextPath is the root context path of the web application. For example, the contextPath of Oracle Identity Federation is either /fed or /shareid.
relativePath is the service URL to which to forward the user; it is relative to the contextPath. For example, after authenticating a user, the Authentication Engine uses /user/loginsso or /saml/ObSAMLLoginService as the relativePath when forwarding the user.
The Authentication Engine needs to be aware that the contextPath of the Oracle Identity Federation server is /fed or /shareid.
Additionally, Oracle Identity Federation needs to be aware of the contextPath and the relativePath of the new Authentication Engine. This is the URL that will process authentication requests issued by the federation server.
Modify the following files to configure these URLs:
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
Each file needs the same set of changes:
In the <authn-mapping> element containing the <authn-method> whose value equals sasso_login_idp_context, modify the value of the corresponding <authn-screen> to the contextPath of the new Authentication Engine; by default, that value is set to /sso.
In the <authn-mapping> element containing the <authn-method> whose value equals sasso_login_idp_url, modify the value of the corresponding <authn-screen> to the relativePath of the new Authentication Engine; by default, that value is set to /authn.
The SAML 1.x and WS-Fed protocols also need to be aware of the contextPath and the relativePath of the new authentication engine. To configure these URLs, modify the $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file like this:
In the <LoginConfig> XML element, locate the <AuthnMethod> element whose Name attribute equals Sasso, and set the LoginURL attribute to the concatenation of the contextPath and the relativePath.
Note:
Due to a limitation for the SAML 1.x/WS-Fed protocols in Oracle Identity Federation, therelativePath can contain only one "/" character; there are no restrictions on the contextPath. For example, contextPath can be set to /path1/path2/path3, while relativePath can only be set to /path4; a value of /path5/path6 for the relativePath is invalid.Restart the OC4J_FED instance after changing the authn-mappings.xml files.
Implementing the Service
This section describes the roles that are played by the authentication engine, and the processing tasks that the service must be able to handle for a successful implementation.
The Authentication Engine needs to:
process requests from the Federation Engine
forward the user to the federation server after a successful authentication
When processing authentication requests from the server, the engine must process the following incoming data:
doneURL query parameter - The relative URL to which the user must be forwarded, after being identified by the Authentication Engine, when the getUsrSess parameter value is not true.
authnMech query parameter - The authentication mechanism requested by the federation server to be used to authenticate the user. In this release, it will always be oracle:fed:authentication:password-protected.
refID query parameter - An identifier referencing data in the federation server. When present, this parameter must be passed back to Oracle Identity Federation when the Authentication Engine forwards the user.
getUsrSess - A boolean parameter indicating whether the user should be redirected to the WS-Fed/SAML 1.x protocol engines instead of to the doneURL parameter.
oracle.security.sso.sasso.authn.dyna_mode HttpServletRequest attribute. This value is always set to idp when local authentication is invoked.
After successful authentication, the engine must forward the user to the federation server. If the getUsrSess parameter was missing or its value is not true, the rootContext of the federation engine is /fed, and the relativePath for this release is /user/loginsso; this relativePath parameter is also stored in the doneURL query parameter. If the getUsrSess parameter is present and its value is true, the rootContext of the federation engine is /shareid, and the relativePath for this release is /saml/ObSAMLLoginService.
Oracle Identity Federation expects this data when processing the internal forward:
oracle.security.sso.sasso.uid - HttpServletRequest attribute of type String containing the user's identifier.
oracle.security.sso.sasso.refID - HttpServletRequest attribute of type String containing the refID query parameter value sent earlier by Oracle Identity Federation.
oracle.security.sso.sasso.authnMech - HttpServletRequest attribute of type String containing the Oracle authentication mechanism identifier that references the method used to authenticate the user. In this release, this value must be set to oracle:fed:authentication:password-protected.
oracle.security.sso.sasso.authnInst - HttpServletRequest attribute of type java.util.Date containing the instant when the user was authenticated.
Here are some additional implementation requirements:
If the service needs to set any cookies, perform this operation before forwarding the user to the federation server.
Set the cookie path value to "/". This is required because of the internal forwards between the Oracle Identity Federation web application and the Authentication Engine web application; the user's browser needs to send the cookies related to the Authentication Engine, even when it is accessing only the federation server. This way, at an internal forward from the federation server to the Authentication Engine, the cookies set by the engine are available in the HTTP Request.
This section describes how to integrate a custom Authentication Engine with OracleAS Single Sign-On.
Setup
In this example, the Application Server where Oracle Identity Federation is running has been integrated with the OracleAS Single Sign-On server, and the SSO module statically protects the /engine/forward.jsp URL.
Additionally, the user data store configured in the Oracle Identity Federation Administration Console references the Oracle Internet Directory server used by OracleAS Single Sign-On.
See Also:
"Deploying Oracle Identity Federation with OracleAS Single Sign-On" for more information on SSO integration.Packaging
The Authentication Engine consists of a Web application with a root context set to /engine, and contains two JSP pages:
authentication.jsp which processes the incoming request from the Oracle Identity Federation server
forward.jsp which is protected by OracleAS Single Sign-On, and which forwards the user back to the federation server with the required data.
Implementation of authentication.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String doneURL = request.getParameter("doneURL");
String authnMech = request.getParameter("authnMech");
String refID = request.getParameter("refID");
String getUserSession = request.getParameter("getUsrSess");
String authnMode = (String)request.getAttribute("oracle.security.sso.sasso.authn.dyna_mode");
if (authnMode != null && !"idp".equals(authnMode))
throw new ServletException("Incorrect authn mode");
String redirectURL = "/engine/forward.jsp?doneURL=" +
(doneURL != null ? URLEncoder.encode(doneURL) : "") + "&refID=" +
(refID != null ? URLEncoder.encode(refID) : "") +
(getUserSession != null && getUserSession.length() > 0 ? "&getUsrSess=" + URLEncoder.encode(getUserSession) : "");
response.sendRedirect(redirectURL);
%>
Implementation of forward.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String doneURL = request.getParameter("doneURL");
String refID = request.getParameter("refID");
String getUserSession = request.getParameter("getUsrSess");
String userID = request.getRemoteUser();
String authnMethod = "oracle:fed:authentication:password-protected";
Date now = new Date();
request.setAttribute("oracle.security.sso.sasso.uid", userID);
request.setAttribute("oracle.security.sso.sasso.refID", refID);
request.setAttribute("oracle.security.sso.sasso.authnMech", authnMethod);
request.setAttribute("oracle.security.sso.sasso.authnInst", now);
if ("true".equals(getUserSession))
request.getSession().getServletContext().getContext("/shareid").getRequestDispatcher("/saml/ObSAMLLoginService").forward(request, response);
else
request.getSession().getServletContext().getContext("/fed").getRequestDispatcher(doneURL).forward(request, response);
%>
Oracle Identity Federation Configuration Files
Modify these files to define the Authentication Engine contextPath and relativePath:
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
Each file needs the same set of changes:
<authn-mapping>
<authn-method>sasso_login_idp_context</authn-method>
<authn-screen>/engine</authn-screen>
</authn-mapping>
<authn-mapping>
<authn-method>sasso_login_idp_url</authn-method>
<authn-screen>/authentication.jsp</authn-screen>
</authn-mapping>
The $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file is modified to define the Authentication Engine URL, and to set the useLocalConfig attribute to true to force changes to be persisted at restart:
<SHAREidConfiguration … useLocalConfig="true">
…
<AuthMethod Name="Sasso"
LoginURL="/engine/authentication.jsp" LogoutURL="/sso/logout" />
</SHAREidConfiguration>"
Logout
Since the OracleAS Single Sign-On framework sets cookies in the user's browser, the authentication engine should be integrated into the logout flow (see "Logout").
This section shows how to integrate a customized Authentication Engine with a standalone LDAP server.
Setup
The user data store configured in the Oracle Identity Federation Administration Console references the LDAP server used by the Authentication Engine.
Packaging
The Authentication Engine consists of a Web application with a root context set to /engine, and contains two JSP pages:
loginpage.jsp, which processes the incoming request from the federation server, and displays the login page.
ldapforward.jsp, which authenticates the user's credentials against the LDAP server; upon success it forwards the user to the federation server.
Implementation of loginpage.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String doneURL = request.getParameter("doneURL");
String authnMech = request.getParameter("authnMech");
String refID = request.getParameter("refID");
String getUserSession = request.getParameter("getUsrSess");
String authnMode = (String)request.getAttribute("oracle.security.sso.sasso.authn.dyna_mode");
if (authnMode != null && !"idp".equals(authnMode))
throw new ServletException("Incorrect authn mode");
String postURL = "/engine/ldapforward.jsp?doneURL=" +
(doneURL != null ? URLEncoder.encode(doneURL) : "") + "&refID=" +
(refID != null ? URLEncoder.encode(refID) : "") +
(getUserSession != null && getUserSession.length() > 0 ? "&getUsrSess=" + URLEncoder.encode(getUserSession) : "");
String msg = request.getParameter("message");
%>
<HTML>
<BODY>
<FORM action="<%=postURL%>" method="POST">
<% if(msg != null && msg.length() > 0) { %> <%=msg%><BR/> <%}%>
Username: <INPUT type="text" name="username"/><BR/>
Password: <INPUT type="password" name="password"/><BR/>
<INPUT type="submit" value="Submit"/>
</FORM>
</BODY>
</HTML>
Implementation of forward.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*, javax.naming.*, javax.naming.directory.*, java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String doneURL = request.getParameter("doneURL");
String refID = request.getParameter("refID");
String getUserSession = request.getParameter("getUsrSess");
String userID = request.getParameter("username");
String password = request.getParameter("password");
String authnMethod = "oracle:fed:authentication:password-protected";
Date now = new Date();
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://stadm14.us.oracle.com:389");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=" + userID + ",cn=users,dc=us,dc=oracle,dc=com");
env.put(Context.SECURITY_CREDENTIALS, password);
try {
DirContext ctx = new InitialDirContext(env);
} catch (NamingException ex) {
String redirectURL = "/engine/loginpage.jsp?doneURL=" +
(doneURL != null ? URLEncoder.encode(doneURL) : "") + "&refID=" +
(refID != null ? URLEncoder.encode(refID) : "") + "&authnMech=" +
URLEncoder.encode(authnMethod) + "&message=" +
URLEncoder.encode(ex.toString() + " for " + userID + " / " + password) +
(getUserSession != null && getUserSession.length() > 0 ? "&getUsrSess=" + URLEncoder.encode(getUserSession) : "");
response.sendRedirect(redirectURL);
return;
}
request.setAttribute("oracle.security.sso.sasso.uid", userID);
request.setAttribute("oracle.security.sso.sasso.refID", refID);
request.setAttribute("oracle.security.sso.sasso.authnMech", authnMethod);
request.setAttribute("oracle.security.sso.sasso.authnInst", now);
if ("true".equals(getUserSession))
request.getSession().getServletContext().getContext("
/shareid").getRequestDispatcher("/saml/ObSAMLLoginService").forward(request, response);
else
request.getSession().getServletContext().getContext
("/fed").getRequestDispatcher(doneURL).forward(request, response);
%>
Oracle Identity Federation Configuration Files
Modify these files to define the Authentication Engine contextPath and relativePath:
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
Each file needs the same set of changes:
<authn-mapping> <authn-method>sasso_login_idp_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_login_idp_url</authn-method> <authn-screen>/loginpage.jsp</authn-screen> </authn-mapping>
The $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file is modified to define the Authentication Engine URL, and to set the useLocalConfig attribute to true to force changes to be persisted at restart:
<SHAREidConfiguration … useLocalConfig="true">
…
<AuthMethod Name="Sasso" LoginURL="/engine/authentication.jsp"
LogoutURL="/sso/logout" />
</SHAREidConfiguration>"
Logout
Since no cookies are set in this flow, the authentication engine is not required to integrate with the logout flow (described in "Logout").
This section explains how to plan, develop, and implement a custom SP integration engine.
See Also:
"Architecture" for a description of the SP Integration Engine and how it fits into Oracle Identity Federation architecture.
"The GenericSPCookieProvider Example" for a description of a working SP Integration Engine.
The steps for developing a custom SP Integration Engine involve:
creating a service to process requests from Oracle Identity Federation in SP mode
implementing a module to create an authenticated session for a user at the IAM server
redirecting the user to the final target URL
deciding whether the SP Integration Engine will set a cookie after it creates an authenticated session at the IAM Server. If so, the engine needs to be integrated into the logout process (see "Logout").
packaging these services and module into a web application, and deploying it to the OC4J_FED instance of the Application Server where the federation server is running
modifying Oracle Identity Federation configuration files to reference the new SP Integration Engine; this requires that OC4J_FED be restarted.
if the SP Integration Engine accesses a user repository, ensuring that it is the same user data store configured in the Oracle Identity Federation Administration Console for use by Oracle Identity Federation
This section describes how to develop the integration module and how to implement it in the federation environment.
URLs
Communication between the Identity Federation Engine and the SP Integration Engine requires internal servlet forwards that are equivalent to API calls. These forwards are achieved with the following J2EE API:
ServletContext.getContext(String contextPath)
.getRequestDispatcher(String relativePath)
.forward(HttpServletRequest request,
HttpServletResponse response)
where
contextPath is the root context path of the web application. For example, the contextPath of the Oracle Identity Federation server is /fed.
relativePath is the service URL to which the uses if forwarded, and is relative to the contextPath. For example, after authentication, the Authentication Engine uses /user/loginsso as the relativePath when forwarding the user.
Oracle Identity Federation needs to be aware of the contextPath and the relativePath of the new SP Integration Engine; these are the URLs publishing the service that interacts with the IAM Server to create an authenticated session. You must modify the $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml file to configure these URLs:
In the <authn-mapping> element containing the <authn-method> whose value equals sasso_login_sp_context, modify the value of the corresponding <authn-screen> to the contextPath of the new SP Integration Engine (by default, this is set to /sso).
In the <authn-mapping> element containing the <authn-method> whose value equals sasso_login_sp_url, modify the value of the corresponding <authn-screen> to the relativePath of the new SP Integration Engine (by default, this is set to /authn).
The SAML 1.x and WS-Fed protocols also need to be aware of the contextPath and the relativePath of the new SP Integration Engine. To configure these URLs, modify the $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file like this: in the <LoginConfig> XML element, locate the <AuthnMethod> element whose Name attribute equals SassoSP, and set the LoginURL attribute to the concatenation of the contextPath and the relativePath.
Note:
Due to a limitation in Oracle Identity Federation for the SAML 1.x/WS-Fed protocols, therelativePath can only contain one "/" character; there are no restrictions on the contextPath. For example, contextPath can be set to /path1/path2/path3, while relativePath can only be set to /path4; a value of /path5/path6 for the relativePath is invalid.To persist these changes, set the useLocalConfig attribute of the top <SHAREidConfiguration> XML element to true.
After changing the authn-mappings.xml and the shareid-config.xml files, restart the OC4J_FED instance.
Implementing the Service
Upon receiving a request from Oracle Identity Federation, the SP Integration Engine needs to:
create an authenticated session for the user
redirect the user to the final URL
The engine must process the following incoming data:
oracle.security.sso.sasso.uid – HttpServletRequest attribute of type String containing the unique user identifier
oracle.security.sso.sasso.authnInst – HttpServletRequest attribute of type java.util.Date containing the user authentication time
oracle.security.sso.sasso.expiryInst – HttpServletRequest attribute of type java.util.Date containing the instant at which the authenticated session should expire
oracle.security.sso.sasso.targetURL – HttpServletRequest attribute of type String containing the final target URL
oracle.security.sso.sasso.authn.dyna_mode – HttpServletRequest attribute of type String. In SP mode, this value is always set to sp.
Using this data, the SP Integration Engine creates an authenticated session and redirects the user to the final target URL.
If the service needs to set cookies, the cookie path must be set to "/". This is necessary because of the internal forwards between the Oracle Identity Federation and SP Integration Engine web applications; the user's browser needs to send the cookies related to the SP Integration Engine, even when accessing only the federation server. This way, when an internal forward occurs from the federation server to the SP Integration Engine, the cookie set by the latter will be available in the HTTP Request.
The next two sections provide examples of implementing a custom authentication engine:
Note:
Oracle strongly discourages users from deploying any applications on the OC4J_FED J2EE container instance other than the ones for custom integration and authentication described as sample integration modules 1 and 2 below, because doing so introduces potential security risks. Extraneous applications deployed in the OC4J_FED container can potentially affect the security of the federation server by allowing rogue software to change the behavior of the server flows.This section shows a simple SP Integration Engine that uses the javax.servlet.http.HttpSession to set an attribute. The presence of this attribute shows whether or not a user is authenticated.
Note:
The example in this section is intended for illustration only and should not be used in a production environment. Indeed, it supposes that other applications deployed on the OC4J_FED instance will consume data set by the SP Integration Engine, which is an approach strongly discouraged by Oracle. Furthermore, this example might not function properly in certain deployments, especially when propagating HttpSession across J2EE applications.Setup
The SP Integration Engine will not interact with the user data store used by Oracle Identity Federation. Several J2EE applications are deployed on the OC4J_FED instance.
Packaging
The SP Integration Engine consists of a Web application with a root context set to /engine, and contains two JSP pages:
oc4jintegration.jsp, which processes the request from the federation server and creates an HttpSession with a feduserid attribute containing the user's identifier
application.jsp, which serves as an application. It looks for the HttpSession's feduserid attribute, and triggers a Federation SSO if the attribute is not found
Implementation of application.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String userid = (String)request.getSession().getAttribute("feduserid");
if (userid == null || userid.length() == 0) {
String redirectURL = "/fed/sp/initiatesso?providerid=" +
URLEncoder.encode("http://stadm14.us.oracle.com:7778/fed/idp") +
"&returnurl=/engine/application.jsp";
response.sendRedirect(redirectURL);
return;
}
%>
Welcome <%=userid%>
Implementation of oc4jintegration.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String userid = (String)request.getAttribute("oracle.security.sso.sasso.uid");
Date authnInst = (Date)request.getAttribute("oracle.security.sso.sasso.authnInst");
Date expirationInst = (Date)request.getAttribute("oracle.security.sso.sasso.expiryInst");
String targetURL = (String)request.getAttribute("oracle.security.sso.sasso.targetURL");
request.getSession().setAttribute("feduserid", userid);
response.sendRedirect(targetURL);
%>
Oracle Identity Federation Configuration Files
The $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml file is modified to define the SP Integration Engine contextPath and relativePath:
<authn-mapping> <authn-method>sasso_login_sp_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_login_sp_url</authn-method> <authn-screen>/oc4jintegration.jsp</authn-screen> </authn-mapping>
The $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file is modified to define the SP Integration Engine URL, and to set the useLocalConfig attribute to true to force the changes to be persisted at restart:
<SHAREidConfiguration … useLocalConfig="true"> .. <AuthMethod Name="SassoSP" LoginURL="/engine/oc4jintegration.jsp" LogoutURL="/sso/logout" /> </SHAREidConfiguration>
Logout
Since this application sets up an HttpSession in the OC4J_FED instance, the SP Integration engine must be integrated in the logout flow (see "Logout").
This section shows an SP Integration Engine that uses a simple Single Sign-On framework based on a cookie containing the username and the expiration time of the authenticated session.
Note:
This example is intended for illustration only and should not be used in a production environment. For example, the cookies set in this example are not encrypted, allowing an attacker to impersonate a user by manually constructing such cookies.Setup
The SP Integration Engine will not interact with the user data store used by Oracle Identity Federation. The Engine will set up a cookie, for the entire domain, containing the user's identifier as a String variable and the session timeout as a long.
Packaging
The SP Integration Engine consists of a Web application with a root context set to /engine, and contains two JSP pages:
domainintegration.jsp, which processes the request from the Oracle Identity Federation server and creates a cookie with the user ID and session timeout
domainapplication.jsp, which serves as an application. It looks for the cookie and triggers a federation SSO if the cookie is not found.
Implementation of domainapplication.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*, java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
Cookie[] cookies = request.getCookies();
String userid = null;
Date timeout = null;
for(int i = 0, size = (cookies != null ? cookies.length : 0); i < size; i++) {
String name = cookies[i].getName();
if ("spintegrationcookie".equals(name)){
String value = cookies[i].getValue();
StringTokenizer st = new StringTokenizer(value, "*");
userid = st.nextToken();
timeout = new Date(Long.parseLong(st.nextToken()));
break;
}
}
if (userid == null || userid.length() == 0) {
String redirectURL = "http://stadm04.us.oracle.com:7778" +
"/fed/sp/initiatesso?providerid=" +
URLEncoder.encode("http://stadm14.us.oracle.com:7778/fed/idp") +
"&returnurl=" + URLEncoder.encode(
"http://stadm04.us.oracle.com:7778/engine/domainapplication.jsp");
response.sendRedirect(redirectURL);
return;
}
%>
Welcome <%=userid%>. You are logged until <%=timeout%>
Implementation of domainintegration.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String userid = (String)request.getAttribute("oracle.security.sso.sasso.uid");
Date authnInst = (Date)request.getAttribute("oracle.security.sso.sasso.authnInst");
Date expirationInst = (Date)request.getAttribute("oracle.security.sso.sasso.expiryInst");
String targetURL = (String)request.getAttribute("oracle.security.sso.sasso.targetURL");
String cookieValue = userid + "*" + expirationInst.getTime();
Cookie cookie = new Cookie("spintegrationcookie", cookieValue);
cookie.setDomain(".us.oracle.com");
cookie.setPath("/");
response.addCookie(cookie);
response.sendRedirect(targetURL);
%>
Oracle Identity Federation Configuration Files
The $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml file is modified to define the SP Integration Engine contextPath and relativePath:
<authn-mapping> <authn-method>sasso_login_sp_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_login_sp_url</authn-method> <authn-screen>/domainintegration.jsp</authn-screen> </authn-mapping>
The $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file is modified to define the SP Integration Engine URL, and to set the useLocalConfig attribute to true to force changes to be persisted at restart:
<SHAREidConfiguration … useLocalConfig="true">
…
<AuthMethod Name="SassoSP" LoginURL="/engine/domainintegration.jsp" LogoutURL="/sso/logout" />
</SHAREidConfiguration>
Logout
Since this sample application sets up a domain cookie, the SP Integration engine must be integrated into the logout flow (see Logout below).
This section explains how to configure logout flows.
During the logout flows, the Identity Federation Engine considers the SP Integration and Authentication engines as a single entity, as illustrated by Figure 4-2:
Here is a description of the action performed by the different Oracle Identity Federation modules when a logout process is being invoked:
The user previously accessed Oracle Identity Federation to perform an SSO operation (in either SP or IdP mode).
The user accesses the Oracle Identity Federation Logout service URL /fed/user/logout with the following query parameter:
returnurl - the URL to which to redirect the user after completion of the logout process [optional]. See "Configuring the Logout Service" for details.
The Oracle Identity Federation user session will be marked as logging out.
Oracle Identity Federation will redirect the user to the servlet responsible for the session termination of the Authentication and SP Integration engines located at the /sso/logout URL. The servlet may interact with the IAM framework to perform the logout operation. The redirect from Oracle Identity Federation to the logout servlet could contain the following query parameters:
invokeOSFSLogout – a boolean value indicating whether the Logout Authentication and SP Integration servlet should redirect the user to the /fed/user/logoutsso URL after having logged the user out from the IAM and the Authentication/SP Integration engines. If this parameter is missing or false, the doneURL parameter should be used to redirect the user after local logout is complete.
doneURL – a URL-encoded value containing the URL to which to redirect the user after having logged out the user from the IAM and the Authentication/SP Integration engines. This parameter is to be used when invokeOSFSLogout is false or missing.
The user is redirected to Oracle Identity Federation to perform the Federation Logout operations with the remote providers.
After the federation logout steps are performed, the Oracle Identity Federation user session is destroyed.
The user is redirected to the returnurl location.
This section contains topics relevant to redirection during logout.
URLs
During the logout operations, the user is being redirected between the Federation Engine and the logout service of the Authentication and SP Integration Engines.
Oracle Identity Federation needs to be aware of the location of the logout service in order to redirect the user to the servlet/jsp page for logout. This URL is defined in the authn-mappings.xml file. The URL can be defined as the union of a contextPath and a relativePath:
contextPath is the root context path of the web application. For example, the contextPath of Oracle Identity Federation is /fed.
relativePath is the service URL to which to forward the user; it is relative to the contextPath. For example, the default logout location of the Authentication and SP Integration Engine is /logout as the relativePath.
Modify the following files to configure these URLs:
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
Each file needs the same set of changes:
In the <authn-mapping> element containing the <authn-method> whose value equals sasso_logout_context, modify the value of the corresponding <authn-screen> to the contextPath of the new Authentication Engine; by default, that value is set to /sso.
In the <authn-mapping> element containing the <authn-method> whose value equals sasso_logout_url, modify the value of the corresponding <authn-screen> to the relativePath of the logout service; by default, that value is set to /logout.
The SAML 1.x and WS-Fed protocols also need to be aware of the contextPath and the relativePath of the new logout service. To configure these URLs, modify the $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file like this:
In the LoginConfig XML element, locate the AuthnMethod element whose Name attribute equals Sasso, and set the LogoutURL attribute to the concatenation of the contextPath and the relativePath.
In the LoginConfig XML element, locate the AuthnMethod element whose Name attribute equals SassoSP, and set the LogoutURL attribute to the concatenation of the contextPath and the relativePath.
In the <LogoutConfig> XML element, set the SassoURL attribute to the concatenation of the contextPath and the relativePath.
Note:
Due to a limitation in Oracle Identity Federation for the SAML 1.x/WS-Fed protocols, therelativePath can only contain one "/" character; there are no restrictions on the contextPath. For example, contextPath can be set to /path1/path2/path3, while relativePath can only be set to /path4; a value of /path5/path6 for the relativePath is invalid.To persist these changes, set the useLocalConfig attribute of the top <SHAREidConfiguration> XML element to true.
Restart the OC4J_FED instance after changing the authn-mappings.xml files.
Implementing the Logout Service
The operations that need to be performed by the logout service include:
processing requests from the Federation Engine
interacting with the IAM framework with which it is integrated to log the user out
redirecting the user to the Federation Engine or to the doneURL parameter, if both Authentication and SP Integration engines bundled with Oracle Identity Federation have been replaced
redirecting the /sso/logout URL with the query parameters passed from Oracle Identity Federation (invokeOSFSLogout and/or doneURL), if only one of the engines, authentication engine or SP Integration engine has been replaced. This is required since one of the default Oracle Identity Federation engines has been used and the user session needs to be logged out from this module.
In the next two sections, these scenarios of logout services are outlined:
Logout Service Example #1 describes a custom logout service when both the Authentication and SP Integration engines are customized
Logout Service Example #2 describes a custom logout service when only the SP Integration engine is customized
This section describes how to integrate a custom Logout Service, assuming that both the Authentication and SP Integration engines have been customized, that is, the default engines are not used anymore.
Setup
In this example, the Authentication Engine is the LDAP engine described in section 3.3.2, and the SP Integration Engine is the OC4J_FED Integration engine described in "Sample Integration Module 1: OC4J_FED Integration".
Packaging
The Logout service consists of a JSP page bundled with the Authentication and SP Integration engines:
logout.jsp, which will process the request from the Oracle Identity Federation server, remove the feduserid attribute from the HttpSession object, set in the oc4jintegration.jsp page, and redirect the user to either Oracle Identity Federation or the doneURL parameter.
Implementation of logout.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String oifContext = "/fed";
String oifLogoutPath = "/user/logoutsso";
String invokeOSFSLogout = request.getParameter("invokeOSFSLogout");
String doneURL;
if ("true".equals(invokeOSFSLogout))
doneURL = oifContext + oifLogoutPath;
else
doneURL = request.getParameter("doneURL");
request.getSession().removeAttribute("feduserid");
response.sendRedirect(doneURL);
%>
Oracle Identity Federation Configuration Files
Modify these files to define the Authentication Engine contextPath and relativePath:
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
Each file needs the same set of changes:
<authn-mapping> <authn-method>sasso_logout_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_logout_url</authn-method> <authn-screen>/logout.jsp</authn-screen> </authn-mapping>
The $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file is modified to define the Logout Service URL in three places, and to set the useLocalConfig attribute to true to force the changes to be persisted at restart:
<SHAREidConfiguration … useLocalConfig="true">
<LoginConfig>
…
<AuthMethod Name="Sasso" LoginURL="/engine/loginpage.jsp"
LogoutURL="/engine/logout.jsp" />
<AuthMethod Name="SassoSP"
LoginURL="/engine/oc4jintegration.jsp" LogoutURL="/engine/logout.jsp" />
</LoginConfig>
<LogoutConfig Protocol="http" HostName="…"
Port="…" SassoURL="/engine/logout.jsp" OsfsURL="/fed/user/logoutwsfed" />
</SHAREidConfiguration>
This section describes how to integrate a custom Logout Service, assuming that only the SP Integration engine has been customized, that is, the default authentication engine is still in use.
Setup
In this example, the Authentication Engine is LDAP standalone, configured through the Oracle Identity Federation Administration Console, and the SP Integration Engine is the OC4J_FED Integration engine described in "Sample Integration Module 1: OC4J_FED Integration".
Packaging
The Logout service consists of a JSP page bundled with the Authentication and SP Integration engines:
logout.jsp, which will process the request from the Oracle Identity Federation server, remove the feduserid attribute from the HttpSession object, set in the oc4jintegration.jsp page, and redirect the user to the /sso/logout URL with the invokeOSFSLogout and doneURL parameters.
Implementation of logout.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String ssoLogout = "/sso/logout";
String invokeOSFSLogout = request.getParameter("invokeOSFSLogout");
String doneURL = request.getParameter("doneURL");
String queryString = "";
if (invokeOSFSLogout != null && invokeOSFSLogout.length() > 0)
queryString = queryString + "invokeOSFSLogout=" + URLEncoder.encode(invokeOSFSLogout);
if (doneURL!= null && doneURL.length() > 0)
{
if (queryString.length() > 0)
queryString = queryString + "&";
queryString = queryString + "doneURL=" + URLEncoder.encode(doneURL);
}
if (queryString.length() > 0)
ssoLogout = ssoLogout + "?" + queryString;
request.getSession().removeAttribute("feduserid");
response.sendRedirect(ssoLogout);
%>
Oracle Identity Federation Configuration Files
Modify these files to define the Authentication Engine contextPath and relativePath:
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
Each file needs the same set of changes:
<authn-mapping> <authn-method>sasso_logout_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_logout_url</authn-method> <authn-screen>/logout.jsp</authn-screen> </authn-mapping>
The $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file is modified to define the Logout Service URL in three places, and to set the useLocalConfig attribute to true to force the changes to be persisted at restart:
<SHAREidConfiguration … useLocalConfig="true">
<LoginConfig>
…
<AuthMethod Name="Sasso" LoginURL="/engine/loginpage.jsp"
LogoutURL="/engine/logout.jsp" />
<AuthMethod Name="SassoSP"
LoginURL="/engine/oc4jintegration.jsp" LogoutURL="/engine/logout.jsp" />
</LoginConfig>
<LogoutConfig Protocol="http" HostName="…"
Port="…" SassoURL="/engine/logout.jsp" OsfsURL="/fed/user/logoutwsfed" />
</SHAREidConfiguration>
Metalink note 427374.1 contains the source code for a working SP Integration Engine. It includes these files:
cookieprovider.jsp, which generates a user cookie
testapplication.jsp, which tests the deployment by looking for the cookie
GenericSPCookieProvider.EAR
The note provides complete details about this working example, including:
a description of what the EAR does;
how to deploy the EAR file to the application server; and
how to test EAR deployment.
This Metalink note is available at http://webiv.oraclecorp.com/cgi-bin/webiv//do.pl/Get?WwwID=note:427374.1.
Oracle Identity Federation can be configured to accept HTTP basic credentials, with or without an identity and access management system, when using SAML 1.0/1.1 or WS-Federation protocols.
Note:
The techniques described in this section are applicable only if Oracle Identity Federation is acting as an IdP. They do not apply if Oracle Identity Federation is the SP.You can configure basic authentication in an environment where Oracle Identity Federation as IdP authenticates users against an identity store such as Oracle Access Manager. A typical flow using the Browser Artifact (or Browser POST) profile is as follows:
A non-browser client wants to federate with an application at an SP, using an Oracle Identity Federation server installed at an IdP. The client sends an HTTP GET request to the IdP.
The Oracle Identity Federation IdP sends a 401 Not Authorized response back to the client.
The client re-sends the GET with an Authorization header containing HTTP basic or NTML credentials that the client has obtained through unspecified means.
The IdP uses the credentials in the Authorization header to authenticate the user against its identity store.
The Oracle Identity Federation IdP then creates an assertion for the user, and (for the artifact profile), associates the assertion with an artifact, and sends a 302 Redirect response to the client for the SP's Assertion Receiver Server with the artifact and the target URL.
The client responds to the redirect by sending a GET request to the SP's Assertion Receiver Service.
The SP's Assertion Receiver Service processes the GET request, determines the IdP from the artifact and sends an Artifact retrieval request to the IdP's SOAP responder service. The IdP returns the assertion associated with the artifact and the SP performs the appropriate processing on the artifact to allow access to the target URL.
The client responds to the redirect by sending a GET request to the application, including any SSO cookie set in step 6.
If the application is protected by a web access manager, the access manager accepts the SSO cookie and allows access to the application. Alternately, the application might directly retrieve the assertion from the SP SAML component and use that to authorize access.
To use HTTP basic authentication for this flow when using Oracle Access Manager (OAM):
Using the OAM Policy Manager, modify the Transfer Service policy in the Fed Domain policy domain (which is automatically set up when you configure Oracle Identity Federation to use OAM) to use a basic authentication scheme. Depending on what OAM setup options were chosen, some pre-configured basic schemes can be used.
Install an OAM OHS WebGate agent into the HTTP_Server component of Oracle Identity Federation. The Transfer Service policy set up in Step 1 will cause WebGate to send the 401 response back to the client, and to use the Authorization header from the client to create an ObSSOCookie, which is then used by Oracle Identity Federation.
Note:
The fix for Oracle Access Manager bug 5736326 is required for this step.You can configure basic authentication in an environment where Oracle Identity Federation does not authenticate users against an identity store. The flow is similar to that described in "Basic Authentication with an Identity Store" earlier.
To configure basic authentication in this scenario, start with the $ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml file. The file contains a LoginConfig element, which looks like this by default:
<LoginConfig AuthMethod="Sasso" LogoutPage="/shareid/logout.jsp"
LoggedInPage="/shareid/loggedIn.jsp" SSOCookieDomain=".us.oracle.com">
<AuthMethod Name="Basic" RealmName="SHAREid Login" />
<AuthMethod Name="Form" LoginPage="/shareid/login.jsp" />
<AuthMethod Name="External" Header="userid" />
<AuthMethod Name="Sasso" LoginURL="/sso/authn" LogoutURL="/sso/logout" />
<AuthMethod Name="SassoSP" LoginURL="/sso/authn" LogoutURL="/sso/logout" />
</LoginConfig>
The default AuthMethod is the Sasso component that was mentioned in "Basic Authentication with an Identity Store", which can only perform a form-based login. If you change the AuthMethod attribute in the LoginConfig element to Basic, it will activate the HTTP basic method for SAML 1.x. If needed you can also configure the realm used in the 401 response in the RealmName attribute.
This section describes how to install and integrate a WebGate component with the HTTP Server bundled with the Oracle Identity Federation server.
This scenario assumes that Oracle Identity Federation is already integrated with Oracle Access Manager, as shown in "Deploying Oracle Identity Federation with Oracle Access Manager" and "Edit User Data Store".
Take these steps for WebGate integration:
Create a new AccessGate using the Access System Console, and install the corresponding WebGate on the Oracle HTTP Server of the Application Server where Oracle Identity Federation is running.
Refer to Oracle Access Manager documentation on how to install WebGate on Oracle HTTP Server.
Modify the login JSP page in Oracle Identity Federation as follows:
Note:
This is needed for certain types of authentication schemes to work properly.Back up the $ORACLE_HOME/j2ee/OC4J_FED/applications/sso/web/jsp/salogin.jsp file.
Edit the $ORACLE_HOME/j2ee/OC4J_FED/applications/sso/web/jsp/salogin.jsp and replace its content with:
<%
response.sendRedirect("/fed/user/sassoredirectlogin?" + request.getQueryString());
%>
Configure Oracle Access Manager policies:
From the Access System Console, go to the policy manager section and select the Fed Domain policy.
Click on the Resources tab.
Check the /shareid resource URL and click Delete.
Click Add to add new resources, with the URLs:
/shareid/saml/userAttributes /shareid/saml/mapping /shareid/sasso
Create an Oracle Access Manager policy for use by WebGate/Oracle Identity Federation:
From the Access System Console, go to the policy manager section.
Create a new policy domain, enter a name and click Save.
Note:
This policy will be used to protect Oracle Identity Federation login process URLs.From the Resources tab, add the URLs:
/fed/user/sassoredirectlogin /shareid/sassologin.jsp
Go to the Default Rule tab and click on the Authentication Rule sub-tab.
Select an authentication scheme to use, for example FORM Based or Basic.
Go to the Authorization Rule tab.
Add a new authorization rule and enable it. Click Save.
Go to the Allow Access sub-tab.
Configure the users who can access Oracle Identity Federation (for example, Anyone for all users) and click Save.
Go to Default Rule tab and choose the Authorization Expression sub-tab.
Add the authorization rule created in the previous step and click Save.
Go to the Policy Domains list.
Select the newly created policy and enable it.
