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.
• Define WebGate Agent – In a hybrid solution agents need to be configured to enable communication across partners.
• 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:
<entry key="AccessByIPAddress">
<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:
<AttributeFilterPolicy id="<host>">
<PolicyRequirementRule xsi:type="Requester" value="http://<OAMhost>:<port>/oam/fed" />
<AttributeRule attributeID="uid">
<PermitValueRule xsi:type="ANY" />
</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
• 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:
<VirtualHost *:<portnumber>>
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:
![](../OUAF_SECURITY_45013/images/FederatedSecurity_MappingOptions.png)
• 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.
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/**.
![](../OUAF_SECURITY_45013/images/FederatedSecurity_AuthenticationPolicy.png)
• 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.
• 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
• 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.