包含在查找更多文档专项支持资源 |  以 PDF 格式下载本书 (5890 KB)
Chapter 3 Integrating Oracle Access ManagerOracle Access Manager (previously known as Oblix NetPoint and Oracle COREid) is an enterprise single sign-on product with many of the same features as Sun OpenSSO Enterprise and CA SiteMinder (previously known as Netegrity SiteMinder). Oracle Access Manager is usually used for both single sign-on and delegated administration. Many companies have an existing Oracle Access Manager deployed to protect both internal and external applications. This chapter describes options for integrating Oracle Access Manager with OpenSSO Enterprise. The chapter also provides instructions for configuring end-to-end Oracle Access Manager single sign-on using OpenSSO Enterprise. The following topics are included in this chapter:
About Oracle Access ManagerOracle has two solutions for web-based single sign-on. One solution is to use the legacy Oracle single sign-on product which is integrated in the Oracle Application Server. Another solution is to use the Oracle Access Manager product, previously known as Oblix Access, with Identity Server. The following major components comprise the Oracle Access System:
Overview of a Typical Oracle Access Manager SessionThe Access Server generates a session token with a URL that contains the ObSSOCookie. When the cookie is generated, part of the cookie is used as an encrypted session token. The encrypted session token contains the following:
If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from logout. The update interval is 1/4th of idle the session timeout parameter. Unencrypted ObSSOCookie data includes the following:
The ObSSOCookie is a secure mechanism for user authentication. When the Access System generates the cookie, an MD-5 hash is taken of the session token. When ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the original cookie contents to be sure no one has tampered with the cookie. MD-5 is a one-way hash, so it cannot be unencrypted. The Access Server does the comparison by hashing the session token again and comparing the output with the hash of the token already present in the Oracle Access Server cookie. If the two hashes do not match, the cookie is corrupt. The system relies on the fact that if someone tampers with the session token, the hashes will not match. Understanding the Oracle Access Manager Use CasesThe following uses cases illustrate common Oracle Access Manager process flows: Single logout for any these of these use cases can be implemented in many ways. The logout for federation use cases must have a link in the partner portal for the following URL:
Single logout can also be achieved using Identity Provider-initiated single logout. Simple Single Sign-On Use CaseSimple single sign-on integration is useful when an Oracle Access Manager instance is already deployed and configured to protect intranet enterprise applications. Additionally, OpenSSO Enterprise is deployed to protect the same intranet applications by honoring the user session obtained by Oracle Access Manager. In the following illustration, both OpenSSO Enterprise and Oracle Access Manager share the same user repository for user profile verification. OpenSSO Enterprise can also be configured to use the Ignore Profile option if it relies on the Oracle Access Manager session for attributes. The following figure illustrates architecture in the simple single sign-on use case. Figure 3–1 Simple Oracle Access Manager Single Sign-On
The following figure illustrates the process flow among components in the Identity Provider environment and Service Provider environment. Figure 3–2 Process Flow for Simple Oracle Access Manager Single Sign-On
Federated Single Sign-On Use CasesThe SAML, ID-FF, and WS-Federation protocols provide cross-domain single sign-on among multiple trusted business entities. These protocols are also used in Identity Federation. Identity Federation involves an Identity Provider, also known as an authentication provider, and a Service Provider where the user authentication session at the Identity Provider is consumed. The following are common use cases in which Oracle Access Manager is enabled for federation protocols:
The deployment examples in this chapter are built upon simple single sign-on integration. You must set up single sign-on before enabling federation. For more information about setting up simple single sign-on, see the Deployment Example: Single Sign-On. After setting up simple single sign-on, you can enable Oracle Access Manager for Federation in either the Identity Provider environment or in the Service Provider environment. In the following examples, both Identity Provider and Service Provider are configured for transient federation. In most use cases, bulk federation is configured between the Identity Provider and Service Provider. In transient federation, users exist only in the Identity Provider environment. The Service Provider honors the user authentication at the Identity Provider, and then creates an anonymous session. The anonymous session enables the Service Provider applications, protected by single sign-on, to be accessed. During SAML interactions, there is a possibility of exchanging user attribute information back to the Service Provider for authorization and other purposes. But that scenario is beyond the scope of this document. Using OpenSSO Enterprise to Enable Oracle Federation in an Identity Provider EnvironmentIn this example, Oracle Access Manager is the authentication provider in an Identity Provider environment and protects some of the intranet applications. OpenSSO Enterprise in this deployment resolves the single sign-on issues among enterprise applications in partner environments while Oracle Access Manager provides authentication. Figure 3–3 Oracle Access Manager Federation in an Identity Provider Environment
The following two figures illustrate the process flow among components in the Identity Provider environment and Service Provider environment. Figure 3–4 Process flow for Oracle Access Manager Federation in an Identity Provider Environment
Figure 3–5 Process flow for Oracle Access Manager Federation in an Identity Provider Environment (continued)
Using OpenSSO Enterprise to Enable Oracle Federation in a Service Provider EnvironmentIn this deployment, Oracle Access Manager is installed and configured in Service Provider Environment to protect legacy applications. Figure 3–6 Oracle Access Manager Federation in a Service Provider Environment
The following two figures illustrate the process flow among components in the Identity Provider environment and Service Provider environment. Figure 3–7 Process Flow for Oracle Access Manager Federation in a Service Provider Environment
Figure 3–8 Process Flow for Oracle Access Manager Federation in a Service Provider Environment (continued)
Installing and Configuring Oracle Access ManagerTo enable the legacy Oracle Access Manager single sign-on applications for SAML 2 federation protocols using OpenSSO Enterprise 8.0, follow these steps:
|
hosted=true |
Change the value to false.
To Configure the Identity Provider OpenSSO
Enterprise for SAMLv2 Identity Provider Protocols
-
Generate the metadata templates on both Identity Provider and Service Provider environments.
You can use one of the following methods:
-
Use the famadm command.
-
Use a browser:
http:host:port/opensso/famadm.jsp
-
At the Identity Provider, run the following command:
famadm create-metadata-templ -y idp_entity_id -u amadmin -f admin_password_file_name -m idp_standard_metadata -x idp_extended_metadata -i idp_meta_alias
where idp_meta_alias is "/idp".
-
At the Service Provider, run the following command:
famadm create-metadata-templ -y sp_entity_id -u amadmin -f admin_password_file_name -m sp_standard_metadata -x sp_extended_metadata -s sp_meta_alias
where sp_meta_alias is "/sp".
-
-
Customize extended metadata.
Use one of the following options:
-
To the Identity Provider extended metadata, add an attribute named AuthUrl.
This URL attribute is used by the SAML protocols to redirect to an OpenSSO Enterprise authentication module. In this use case, the redirect is to the custom Oracle Authentication Module. Example:
<Attribute name="AuthUrl"> <Value>http://host:port/opensso/UI/Login?module=OAMAuth</Value> </Attribute>
-
Make the custom Oracle authentication module as the default login module in OpenSSO Enterprise.
A consequence of using this option is that you have to specify an LDAP login module for logging in as adminstrator. The Service Provider extended metadata has an attribute named as transientUser. Set this value to your anonymous user. Example:
<Attribute name="transientUser"> <Value>anonymous</Value> </Attribute>
-
-
Change the hosted attribute in the Identity Provider and Service Provider extended metadata when loading remote metadata.
For a remote Identity Provider or Service Provider, set the value to "false" or "0".
-
Load the metadata.
-
Create circle of trust.
Add the circle of trust to the extended metadata. In the extended template files, you will see a sample circle of trust. Edit the following to correspond to your circle of trust.
<Attribute name="cotlist"> <Value>samplesaml2cot</Value> </Attribute>
-
Load the hosted metadata in both the Identity Provider and Service Provider.
You can use either the famadm command or the OpenSSO Enterprise console.
-
Exchange the metadata .
Import the Service Provider metadata into the Identity Provider, and import the Identity Provider metadata into the Service Provider.
-
Load the metadata.
-
-
After successfully exchanging the metadata, verify through the OpenSSO Enterprise administration console that the metadata has been configured correctly.
To Configure Oracle Access Manager Agent to protect OpenSSO Enterprise URLs
There are many different ways to configure Oracle Access Manager Policy to protect OpenSSO Enterprise URLs. At minimum, you must configure a policy to protect the SAML Single Sign-On Service URL. The real-time policy can be different based on other deployment requirements. The Oracle Access Manager session must be established before the SAML Assertion is generated.
In Oracle Access Server Policy Console, create a policy domain named fampolicy to protect only the OpenSSO Enterprise Single Sign-On Service URL.
Figure 3–10 Creating a policy domain
To Configure the Service Provider
-
Install the OpenSSO Enterprise web policy agent in the Service Provider environment to protect OpenSSO Enterprise Service Provider.
Follow the instructions in the Sun Java System Access Manager Policy Agent 2.2 Release Notes.
There is no restriction on the type of policy agent you use. However, be sure use an agent that is supported on the container where the application to be protected is deployed.
-
Change the policy agent login URL.
After verifying that simple single sign-on with the OpenSSO Enterprise works properly, change the policy agent login URL to the OpenSSO Enterprise SAML2 SP initiated Single Sign-on Service URL. Example:
http://<sphost>:<spport>/opensso/saml2/jsp/spSSOInit.jsp?metaAlias =<SP MetaAlias> &idpEntityID=<IDP Entity ID>&NameIDFormat=transient
To Test the Single Sign-On
-
Authenticate at Oracle Access Manager with username and password.
-
Access the enterprise application protected by the OpenSSO Enterprise Service Provider policy agent in the Service Provider environment.
You should automatically be granted access to the protected application.
Using OpenSSO Enterprise to Enable Oracle Federation in a Service Provider Environment
To enable Oracle Access Manager for Federation in the Service Provider environment, follow these steps:
-
Install OpenSSO Enterprise in the Identity Provider environment.
-
Install OpenSSO Enterprise in the Service Provider environment.
-
Install Oracle Access Manager in the Service Provider domain.
-
Configure Oracle Access Manager for the OpenSSO Enterprise scheme.
-
Configure the OpenSSO Enterprise Identity Provider and Service Provider for SAML2 protocols.
Installing OpenSSO Enterprise in the Identity Provider Environment
The Identity Provider does not have to be an OpenSSO Enterprise deployment. But for optimum protocol interoperability, use OpenSSO Enterprise. See the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guidefor detailed installation and configuration steps.
A good practice is to install the Identity Provider and Server Provider in different domains. If that is not possible, make sure they use different cookie names or cookie domains. This eliminates cookie validation inconsistency.
Installing OpenSSO Enterprise in the Service Provider Environment
See the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guidefor detailed installation and configuration steps.
The OpenSSO Enterprise in the Service Provider environment initiates the SAML2 protocols. The Oracle Access Manager Agent can protect the enterprise application by redirecting to OpenSSO Enterprise for single sign-on purposes.
Installing Oracle Access Manager
Install Oracle Access Manager in the Service Provider domain where enterprise applications are protected by Oracle WebGate agents. See the Oracle Access Manager Installation Guide for detailed installation instructions.
The plug-in name must be same as the name of the shared library.
Figure 3–11 The plug-in name must be same as the name of the shared library
Configuring Oracle Access Manager for an OpenSSO Enterprise Scheme
The custom authentication scheme for Oracle Access Manager is a C-based implementation, and the custom authentication scheme should be built like a shared library. The custom authentication scheme in this chapter is a Solaris-based shared library and can be ported onto other platforms with similar semantics. This custom authentication module also uses the OpenSSO Enterprise C-SDK for validating the OpenSSO Enterprise session. When an OpenSSO Enterprise WAR file is exploded, the custom authentication module is located under the base-dir/samples/thirdparty/oblix directory. The README.txt contains instructions for configuring the Oracle Access Manager authentication scheme. The following figure provides some details for configuring OpenSSO Enterprise AuthSchemein Oracle Access Manager.
Figure 3–12 Configuring OpenSSO Enterprise AuthSchemein Oracle Access Manager
Configuring a Resource
For detailed instructions, see the Oracle Containers for J2EE Security Guide
Later you will use the resource name you configure in Oracle Access Manager in the SAML Adapter configuration. The policy will trigger the OpenSSO Enterprise authentication module.
Setting Up SAMLv2
In all, you must have Identity Provider metadata and extended metadata, as well as Service Provider metadata and extended metadata. In the Identity Provider, import Identity Provider metadata and extended metadata as hosted metadata. Import Service Provider metadata and extended metadata as remote entity metadata. To change the hosted or remote attributes, locate the extended metadata XML element <EntityConfig> which contains the following attribute with default value:
hosted=true |
Change the value to false.
To Configure the OpenSSO Enterprise Identity
and Service Providers for SAML2 Protocols
-
Generate the metadata templates on both Identity Provider and Service Provider environments.
Use the famadm command, or used use a browser to go to the following URL:
http:<host>:<port>/opensso/famadm.jsp
-
At the Identity Provider:
famadm create-metadata-templ -y idp_entity_id -u amadmin -f admin_password_file_name -m idp_standard_metadata -x idp_extended_metadata -i idp_meta_alias
where idp_meta_alias is /idp
-
At the Service Provider:
famadm create-metadata-templ -y sp_entity_id -u amadmin -f admin_password_file_name -m sp_standard_metadata -x sp_extended_metadata -s sp_meta_alias
where sp_meta_alias is /sp
-
-
Customize the Service Provider extended metadata.
Add the Service Provider extended metadata as an attribute named as spAdapter. This attribute is used by the SAML protocols to do any post single sign-on authentication processes. In the architecture diagram, this the Oracle Access Manager Plug-in. The OAMPlugin uses the OpenSSO Enterprise session to authenticate against Oracle Access Manager and establish ObSSOCookie. The Service Provider metadata must have the following attributes:
<Attribute name="spAdapter"> <Value>com.sun.identity.saml2.plugins.SMAdapter</Value> </Attribute> <Attribute name="spAdapterEnv"> <Value>FAMCookieName=iPlanetDirectoryPro</Value> <Value>OAMCookieName=ObSSOCookie</Value> <Value>CookieDomain=.red.example.com</Value> <Value>Resource=/test/index.html</Value> <Value>ObSDKInstallDir=/export/oam/AccessServerSDK</Value> </Attribute> -
Set the value for transientUser to the anonymous user.
The Service Provider extended metadata has an attribute named as transientUser. Make sure that the OpenSSO Enterprise Service Provider is enabled for Anonymous authentication.
<Attribute name="transientUser"> <Value>anonymous</Value> </Attribute>
-
Create a circle of trust.
The circle of trust should also be added in your extended metadata.
-
Load the metadata.
-
Edit the following attribute to one of your circle of trust.
The extended template files contains a sample circle of trust.
<Attribute name="cotlist"> <Value>samplesaml2cot</Value> </Attribute>
You can also add the circle of trust through the OpenSSO Enterprise administration console.
-
Load the hosted metadata in both the Identity Provider and Service Provider.
You can use the famadm command or the OpenSSO Enterprise administration console.
-
Exchange the metadata between Identity Provider and Service Provider.
and load the metadata.
-
Verify through OpenSSO Enterprise administration console that the metadata is configured properly.
Verifying that Single Sign-On Works Properly
Access the enterprise application protected by Oracle WebGate. Oracle WebGate redirects to OpenSSO Enterprise for authentication where the SAML2 single sign-on is initiated.