Federated Online Authentication

The most common scenario is to federate the authentication of online users to a hybrid cloud solution.

Overview

The process for configuring an architecture for federation is as follows:

• Install/Provision all the software on the various platforms ready for configuration. The installation and configuration documentation will outline the steps involved in getting the software installed and configured at a basic working level.

• Identity Provider Configuration - Setup your Identity Provider (IdP) to point to your security repositories and accept the necessary SAML 2.0 request to format the appropriate SAML 2.0 response.

• Oracle HTTP Server/WebGate Configuration - Configure your proxy servers to accept requests and, optionally, support reverse proxy (to detect the client connection).

• Define Identity Provider Partner in Oracle Access Manager – Configure the access management solution with the details of the Identity Provider.

• Enable Just In Time Provisioning in Identity Federation – Whilst the user would exist in the security repository and the product, it needs to be in the access management repository on first use.

• Define WebGate Agent – In a hybrid solution agents need to be configured to enable communication across partners.

• Copy WebGate Agent Configuration to OHS/WebGate – As agents need to communicate effectively ensure that the agent configurations match.

• Define Authentication Policy for the Product Domain – The domains must be configured with the linking policies to link all the components together.

• Export the OAM SAML Metadata (optional) – Optionally, each provider may differing SAML formats. This step exports the suggested format from the access management software into the Identity Provider to ensure SAML responses are formatted correctly.

The steps outlined above are described in the next subsections.

Note: All configuration files shown in this section are examples for illustrative purposes only. Refer to documentation provided with products for details of related settings.

Identity Provider Configuration

The Identity Provider (IdP) in the solution needs to be configured to allow SAML requests and appropriate responses to be received and sent to the service providers (SP) accessing the solution. The actual steps involved will vary from provider to provider but in general the following must be performed:

• The Identity Provider (or its networking component) must be configured to allow connections from the browsers access to the provider. This can be hostnames, IP addresses or IP Address ranges allocated to your users. These addresses can be via Virtual Private networks or direct according to your networking policies. For example, in a Shibboleth installation, the allowedRanges in the access-control.xml configuration file needs to be set:

<bean parent="shibboleth.IPRangeAccessControl"

p:allowedRanges="#{ {'127.0.0.1/32', '::1/128', '<validIpRangePattern>} }" />

</entry>

• Oracle Identity Federation uses the uid LDAP attribute for user identification. Ensure your Identity Provider uses this identifier in any communication to the solution. For example, in a Shibboleth installation, the Requester should be Oracle Access Management (with Oracle Identity Federation installed) with uid as the AttributeRule in the attribute-filter.xml configuration file:

</AttributeRule>

</AttributeFilterPolicy>

• Some Identity Providers require that the IdP be defined explicitly. For example, in a Shibboleth installation, the idp.entityID property must be set in the idp.properties configuration file:

idp.entityID= https://ouaf.oracle.com/idp/shibboleth

Note: Refer to Entity Naming for a description of this setting.

• Configure your Identity Provider to connect to your LDAP security repository. Refer to the documentation with your Identity Provider for detailed information on this process. For example, in a Shibboleth installation, the ldap.properties file controls the interface to the LDAP.

Note: If your implementation uses trust stores, ensure that the trust is also configured correctly for handshaking between the Identity Provider and LDAP security repository.

• Some Identity Providers need to understand the SAML request and response from/to the Oracle Access Management solution. The provider needs to understand how to download the SAML metadata to understand the interface. For example, in a Shibboleth installation, the metadata-providers.xml configuration file needs to be configured:

<MetadataProvider id="HTTPMetadata"

xsi:type="FileBackedHTTPMetadataProvider"

backingFile="%{idp.home}/metadata localCopyFrom_https_<OAMhost>_<port>.xml"

metadataURL="https://<OAMhost>:<port>/oamfed/sp/metadata">

</MetadataProvider>

• Some Identity Providers specify their meta data for use with the Service Provider. Ensure the Identity Provider also has correct certificate usage (including X.509) for secure transmission of data. It is important that signing and encryption certificate match the certificates used in the architecture to avoid issues (such as "Signature verification failed for provider ID…" errors). Refer to Doc Id: 2032605.1 from My Oracle Support for more details. For example, in a Shibboleth installation, the X509 signing and encryption certificates in the idp-metadata.xml configuration file should match the certificates in idp-signing.crt and idp-encrpytion.crt files. In a default installation of Shibboleth the certificates are in the credentials subdirectory. Correct if necessary.

• This should complete the configuration of the Identity Provider.

Oracle HTTP Server/WebGate Configuration

Install and configure the Oracle HTTP Server (aka Web Tier) and the Oracle Access Manager Web Gate as per the Installation Guide.

It is recommended that reverse proxy be configured for Oracle HTTP Server to be used with your application to enable content served by different servers to appear as if coming from a single server.

To enable the reverse proxy functionality alter the Oracle HTTP Server httpd.conf configuration file with the following example section:

ProxyPreserveHost On

ProxyPass "<context>" "https://<producthost>:<productport>/"

ProxyPassReverse "<context>" "https:// <producthost>:<productport>/"

</VirtualHost>

Where:

<port>	Port Number allocated to proxy (default: 7777).
<producthost>	Host Name or cluster address for product.
<productport>	Port or cluster port for product.
<context>	The Product context as configured in the WEB_CONTEXT_ROOT setting in the ENVIRON.INI configuration file (For example: /spl).

For more information and alternatives refer to the Reverse Proxy Guide.

Define Identity Provider Partner in Oracle Access Manager

The Oracle Access Manager with Oracle Identity Federation needs to define the Identity Provider for the redirect and the integration between the products.

Oracle Identity Federation needs to be configured to identify the IdP and its interface. Refer to the Managing Identity Federation Partners documentation for details of the configuration settings.

Using the Federation Launch Pad  Service Provider Management  Identity Provider Partner option, ensure that the following is configured:

• Enable the partner using the Enable Partner function in the Identity Provider Partner portal within Oracle Identity Federation/Oracle Access Manager.

• Load the SAML 2.0 Metadata that was exported from your IdP (or enter it manually). For the example Shibboleth interface, this is located in the idp-metadata.xml configuration file.

• Configure the User Mapping to refer to the following:

• Select the appropriate Identity Store that was configured for your Access Management solution. This is used for Single Sign On.

The userid needs to be explicitly identified via the Universal Resource Name (URN) in the SAML metadata from the IdP metadata. For example:

• The above attribute must be mapped to the uid attribute in Oracle Access Manager

• Optionally, set Enable global logout and HTTP POST SSO Response Binding for SSO integration.

• Within Oracle Access Manager, use the Create Authentication Scheme and Module option to generate and implement the definitions. If necessary, this generated configuration can be viewed or altered using Access Manager  Authentication Schemes and Plug-ins  Authentication Modules respectively.

For example, for the example Shibboleth interface refer to Oracle Interoperability for additional detailed instructions.

Enable Just In Time Provisioning in Identity Federation

The Oracle Access Manager authenticator requires that the SAML assertion from the IdP exists in the Oracle Access Manager Identity Store.

When a new user logs in to the solution for the first time, the user exists in the IdP and in the application’s User object, but it also needs to exist in the Identity Store to complete the login. As the user already is in the IdP and User object, it is recommended to provision the user in the Identity Store automatically (also known as Just In Time Provisioning) upon first login.

This is achieved by setting the userprovisionenabled configuration setting to true within Oracle Access Manager. Refer to JIT User Provisioning in OIF / SP and Oracle Access Manager Administration for more information.

Configure the credentials for access setting the Bind DN to the connection group and the Identity Store on the User Identity Stores as per the Registering and Managing User Identity Stores.

Define WebGate Agent

Within Oracle Access Management, the OAM Agent for the application must be registered and configured with the following settings at a minimum:

• Set the Security to Simple (or Cert for two way certificate implementations).

• Set Auto Create Policies to create default access policies.

• Set the Base URL to the Oracle HTTP Server/Webgate used for the product.

• Set the Access Client Password to the password for the Webgate.

• Set the Relative URI to the WEB_CONTEXT_ROOT setting in the ENVIRON.INI (prefixed with /) in the Protected Resource List. For example, /spl.

• It is recommended to add the User Defined Parameter. authorizationResultCacheTimeout to 0 to avoid Invalid SAML Assertion errors.

Refer to Introduction to Agents and Registration for more information.

Copy WebGate Agent Configuration to OHS/WebGate

Ensure that the configuration in the previous step is available to the Oracle HTTP Server/Web Gate configuration is transferred to the config directory as per the Registering an OAM Agent Using the Console.

Define Authentication Policy for the Product Domain

To link the Oracle Access Manager and the IdP, an Authentication Policy must be configured to connect the WebGate to the IdP for communications. The following process is recommended at a minimum:

• An Application Domain is automatically created by the WebGate configuration implementation. This will be used by the process.

• Create an Authentication Policy for the selected domain with the authentication scheme appropriate for the IdP.

• Set the Resources to the protocol and resource URLs (set to the WEB_CONTEXT_ROOT setting in the ENVIRON.INI, prefixed with / and suffixed with *, for example /ouaf*) as a Protected Resource Policy.

• Repeat the above step for subdirectories under the context, for example, /ouaf/**.

• Set the Operations to All and ensure the Authentication Policy is set correctly for the IdP for each policy.

Export the OAM SAML Metadata (optional)

If the IdP requires to understand the format of the messages from the Oracle Access Manager SAML request and format the response it is recommended to export the definition using the Export SAML 2.0 Metadata option on the provider. Refer to Managing Settings for Identity Federation for more information.

Refer to the documentation of the IdP for how to import the settings into that product. For the example Shibboleth interface, this is not required as this is automatically performed as part of the handshaking process.

Configure the Product Identity Asserter and Authenticators

The security realm in the product Oracle WebLogic domain must be set to do the following:

• Configure the Oracle Access Manager Identity Asserter to provide the identity from the transaction flow to the product.

• Configure the Custom Authentication Service Provider that is available with the product to participate in the authentication process.

• If Oracle Unified Directory is used, as a supplemental security repository, then its Authentication Adapter must be configured to participate in the authentication process.

• If the Default Authenticator is used, as a supplemental security repository, then it must be configured to participate in the authentication process. This Authenticator is used by the administration consoles to administrate the product.

Oracle Access Manager Identity Asserter

For Oracle Access Manager to participate in the authentication the OAMIdentityAsserter must be added to your security realm as an Authentication Provider as per the Implementing the Security Provider. The following should be setup for federated security:

• Set the Type to OAMIdentityAsserter.

• Set the Control Flag to SUFFICIENT. This tells the security system that if the user existence is confirmed by this adapter then it is a valid user.

• Set the Active Types to OAM_REMOTE_USER and OAM_IDENTITY_ASSERTION. This denotes the login types used by federation.

Custom Authenticator

Note: Use of the Custom Authenticator Service Provider is optional and only recommended for sites with more than one security repository that requires adjudication.

Oracle Utilities Application Framework applications ship with a Custom Authentication Service Provider, which checks that the user is defined to the product, in the User object, and that User object is active. Set the Control Flag for this Authenticator Service Provider to SUFFICIENT. Refer to Implementing the Security Provider for more details of this adapter.

If you are using Unified Authenticator and/or the Default Authenticator for system and administration account, then the following should be configured in the Plugin Properties:

• Set the userGroup property to the user group used for the subsetting the users accessing this plugin.

• Set the excludeUsers property to the comma separated list of system and administration users that are not checked by this plugin. This assumes they will be checked by other authentication providers.

• Optionally set the debug property to true for non-production debugging of your configuration to send debug log messages to the Web Server logs.

Oracle Unified Authenticator (optional)

Note: Oracle Unified Directory is used in this example but any LDAP based security repository can be used in its stead using the LDAP Adapter.

If you have administration users that are not defined to your IdP but need to administrate the domain then they should either be defined in the Default Authenticator or an Oracle Unified Authentication Provider. For the latter, refer to Using OUD as a WebLogic Authentication Provider or Configuring An Authentication Provider for Oracle Unified Directory. Set the Control Flag for this Authenticator Service Provider to SUFFICIENT.

Default Authenticator

Typically, implementations would continue to use the inbuilt Default LDAP server (DefaultAuthenticator) for the user identities used by the product to start and stop each component (for example, the system or weblogic account). It is highly recommended that these types of accounts need to be defined in at least one security repository defined in the security realm. Set the Control Flag for this Authenticator Service Provider to SUFFICIENT.

Provider Ordering

• The most important aspect of configuring multiple authentication providers is to order them in the right order to optimize the login process. Reordering can be performed as outlined in Changing the Order of Authentication Providers with the following guidelines:

• It is highly recommended that Oracle Access Manager Identity Asserter and Custom Authenticator be placed first and second respectively. This will ensure the bulk of the users are authenticated efficiently.

• If the Oracle Unified Authenticator (optional)is used, then it can be placed in the third place to catch administration accounts. It can also be placed in second place, if it is required, but if that is before the Custom Authenticator then the group used for authentication, for example cisusers, must also be defined in Oracle Unified Directory.

• It is recommended that the Default Authenticator be placed last as it is typically only used for the accounts that start and stop the product.

Configure CLIENT-CERT

The last step in the online federation process is to configure the login method used by the application. For federation, it is highly recommended to set the login method to CLIENT-CERT which tells the product domain that authentication is coming from an external source. Failure to set this correctly will result in the login screen to be displayed upon connection, which is not desirable in a Single Sign On based solution.

Refer to the Server Administration Guide supplied with your product to set this value.