This chapter includes the following topics:
Permissions
To perform the tasks in this chapter, you must be granted the WebLogic Server Admin
role through the Oracle WebLogic Server Administration Console. Users with the Monitor
or Operator
roles can view security information but cannot make changes.
See also, Understanding Administrative Operations, Roles, and Tools.
Single sign-on provides authentication across a topology’s components allowing users to log in once, rather than having to log in each time they access a component. Without implementing single sign-on, users must provide credentials each time they access components, such as discussions or Content Server, from WebCenter Portal.
Single sign-on can be implemented for WebCenter Portal using several solutions. This section describes their benefits and recommended application.
Oracle Access Manager (OAM), part of Oracle's enterprise class suite of products for identity management and security, provides a wide range of identity administration and security functions, including several single sign-on options for WebCenter Portal. OAM (in particular, OAM 11g) is the recommended single sign-on solution for Oracle WebCenter Portal 12c installations.
For non-production, development environments where you do not have an enterprise-class single sign-on infrastructure like Oracle Access Manager or Oracle SSO, and you only need to provide a single sign-on capability within WebCenter Portal and associated Web tools like discussions, you can configure a SAML-based SSO solution. If you need to provide single sign-on for other enterprise applications as well, this solution is not recommended.
If your enterprise uses Microsoft desktop log-ins that authenticate with a Microsoft domain controller with user accounts in Active Directory, then configuring SSO with Microsoft Clients may also be an option to consider.
Oracle Access Manager (OAM) provides flexible and extensible authentication and authorization, and provides audit services. This section describes how to configure WebCenter Portal for OAM single sign-on authentication, including how to configure the WebLogic server side and the WebCenter Portal application as the partner application participating in SSO.
The installation and configuration steps for OAM 11g are presented in the following topics:
Figure 28-1 shows the components and topology required to set up single sign-on with Oracle Access Manager for a WebCenter Portal application.
Figure 28-1 OAM Single Sign-On Components and Topology
OAM consists of the following components:
Access Server – a standalone server that provides authentication, authorization, and auditing services for Access Gates. There is one access server set up on OAM. This is done as part of the OAM install itself.
WebGate – an out-of-the-box plug-in that intercepts Web resource (HTTP) requests and forwards them to the Access Server for authentication and authorization.
Identity Assertion Provider (IAP) – a type of security provider that asserts the identity of the user based on header information that is set by perimeter authentication. The OAM integration provides an OAM ID Asserter that can be configured as the OAM IAP. The OAM ID Asserter can be used for authentication or for identity assertion. For OAM SSO integration, the OAM ID Asserter should be configured as an Identity Assertion Provider (IAP) by selecting obSSOCookie
under Active Types in the provider's Common settings.
OAM Single Sign-on Process Flow
Figure 28-2 shows the single sign-on process flow for OAM.
Figure 28-2 OAM Single Sign-on Process Flow
SSO Log-in Processing with OAM Agents
The user requests a resource.
The WebGate forwards the request to OAM for policy evaluation.
OAM:
Checks for the existence of an SSO cookie.
Checks policies to determine if the resource protected and if so, how?
The OAM server logs and returns decisions.
WebGate responds as follows:
Unprotected resource: resource is served to the user.
Protected resource:
Request is redirected to the credential collector
The login form is served based on the authentication policy
Authentication processing begins
User sends credentials.
OAM verifies credentials.
OAM starts the session and creates the following host-based cookies:
One per partner: OAMAuthnCookie
set by 11g WebGates (ObSSOCookie
set by 10g WebGate) using the authentication token received from the OAM server after successful authentication.
Note: A valid cookie is required for a session.
One for OAM Server: OAM_ID
OAM logs Success or Failure.
OAM Credential collector redirects to WebGate and authorization processing begins.
WebGate prompts OAM to look up policies, compare them to the user's identity, and determine the user's level of authorization.
OAM logs policy decision and checks the session cookie.
OAM Server evaluates authorization policies and cache the result.
OAM Server logs and returns decisions
WebGate responds as follows:
If the authorization policy allows access, the request get redirected to mod_wl
which in turn redirects the request to the WLS server where the WebCenter Portal application is running, and from where desired content or applications are served to the user, as shown below:
WebGate -> mod_wl -> WebCenter Portal application [, discussions, .. etc] --> Content is served to the authenticated user
If the authorization policy denies access, the user is redirected to another URL determined by the administrator.
Figure 28-3 and Table 28-1 provide an overview of the prerequisites and tasks required to configure single sign-on for WebCenter Portal using OAM.
Figure 28-3 Configuring Single Sign-on for WebCenter Portal Using OAM
Table 28-1 shows the tasks and subtasks for configuring single sign-on for WebCenter Portal using OAM.
Table 28-1 Configuring Single Sign-on for WebCenter Portal Using OAM
Actor | Task | Subtask | Notes |
---|---|---|---|
Administrator |
Install and configure OAM 11g. |
||
2.c Configuring the Default Authenticator and Provider Order |
|||
4.e Configuring the WebLogic Server Administration Console and Enterprise Manager for OAM 11g |
|||
This section describes how to install and configure OAM 11g, and includes the following topics:
Note:
OAM should be installed only after you've installed Oracle WebCenter Portal (described in Installing and Configuring Oracle WebCenter Portal) and any other components required for your environment. You should also have configured and tested any required connections.
Install Oracle Access Manager (OAM) as described in Installing and Configuring Oracle Identity Management in Installation Guide for Oracle Identity Management. Ideally, OAM and all the applications that participate in single sign-on should share the same identity store. By default, OAM uses the embedded LDAP identity store.
To configure OAM to use an external identity store, such as OID, see Registering a New User Identity Store in Administrator's Guide for Oracle Access Management. This section has pointers to setting the external identity store configured as the default or system store and configuring one or more authentication modules to point to this store. By default, the WebCenter policy configured in OAM uses the default authentication scheme (typically, the form-based authentication scheme LDAPScheme
) specified in OAM.
If you intend to use the default scheme, the authentication module used by the scheme must point to the same identity store as your WebCenter installation. Optionally, you can choose to configure a different authentication scheme rather than the default, in which case you must also ensure that it points to the identity store used by WebCenter. Continue by configuring Oracle Access Manager in a WebLogic administration domain as described in Installing and Configuring Oracle Identity Management in Installation Guide for Oracle Identity Management.
If you don't already have Oracle HTTP Server (OHS) installed, install OHS as described in Installing and Configuring the Oracle HTTP Server.
After installing, continue by installing the WebGate as described in Installing the WebGate on the Web Tier.
This section describes how to install and configure the OHS WebGate.
Note:
Ensure that your Oracle HTTP server is down while installing OHS WebGate, and restart it only after you register the WebGate agent as described in Registering the WebGate Agent.
After installing the WebGate on the web tier, you also need to register the WebGate agent. The steps below will automatically create a protected policy that uses the default Authentication Scheme that is configured in your OAM installation (typically, the form-based authentication scheme LDAPScheme
). If you want to customize the single sign-on login page, or want resources to be protected by some other authentication scheme, then change it using the OAM Console (see Managing Authentication Schemes in Administrator's Guide for Oracle Access Management for more information).
Note:
If you are using WebCenter Portal in conjunction with other applications in your environment, and you require single sign-on for these applications, you must ensure that the authentication schemes used by these applications are either the same or at least at the same level and point to the same identity store.
For more information about registering the WebGate agent, see also Getting Started with a New Oracle HTTP Server 11g WebGate in Installing WebGates for Oracle Access Manager.
Follow the steps below to register the WebGate agent on the machine where OAM is installed using the oamreg
tool in inband mode:
Change directories to <RREG_Home>
/input
(where <RREG_Home>
is the directory to where you extracted the contents of RREG.tar.gz/rreg
).
Copy over $WEBCENTER_HOME/webcenter/scripts/webcenter.oam.conf
from the Oracle WebCenter Portal installation here.
The default location for WEBCENTER_HOME
is $ORACLE_HOME/Oracle_WC1
.
Copy over $SOA_HOME/soa/prov/soa.oam.conf
and $WC_CONTENT_ORACLE_HOME/common/security/oam.conf
from the SOA and Content Server installations respectively.
The default location for SOA_HOME
is $ORACLE_HOME/Oracle_SOA1
and the default location for WC_CONTENT_ORACLE_HOME
is $ORACLE_HOME/Oracle_ECM1
. Note that the SOA-related location mappings contained in soa.oam.conf
only come into effect when deploying and using WebCenter Portal-provided work flows on a SOA server, and that even the SOA related URLS protected within webcenter.oam.conf
will come into effect if SOA is being used.
Create a new file named WebCenterOAM11gRequest.xml
to serve as a parameter file to the oamreg
tool.
In the example below, replace the contents within $$webtier..$$
with your web tier host and port IDs, and $$oam...$$
with the OAM host and administration server port.
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved. NAME: OAM11GRequest_short.xml - Template for OAM 11G Agent Registration Request file (Shorter version - Only mandatory values - Default values will be used for all other fields) DESCRIPTION: Modify with specific values and pass file as input to the tool. --> <OAM11GRegRequest> <serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress> <hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier> <agentName>$$webtierhost$$_webcenter</agentName> <logOutUrls> <url>/oamsso/logout.html</url> </logOutUrls> </OAM11GRegRequest>
Change directories to <RREG_Home>
.
Run the following command:
<RREG_Home>/bin/oamreg.sh inband input/WebCenterOAM11gRequest.xml
When prompted for agent credentials enter your OAM administrator credentials.
Enter your WebGate password.
Enter yes
when asked whether you want to import a URIs file. Specify the full path to the <RREG_HOME>/input/webcenter.oam.conf
file you copied there earlier.
You should see output like that below indicating that registration has been successful:
---------------------------------------- Request summary: OAM11G Agent Name:example_webcenter URL String:example_webcenter Registering in Mode:inband Your registration request is being been sent to the Admin server at: http://example.com:7001 ---------------------------------------- Inband registration process completed successfully! Output artifacts are created in the output folder.
Copy the generated files and artifacts (ObAccessClient.xml
and cwallet.sso
) from <RREG_Home>
/output/
$$webtierhost$$
_webcenter
to your WebGate instance configuration directory (<Webgate_Instance_Directory>/webgate/config
). Note that <Webgate_Instance_Directory>
should match the instance home of OHS, as in the following example:
<MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config
Change directories to <RREG_Home>
/input
.
If you have SOA or WebCenter Content Server installed
Create a policy update file called WebCenterOAM11gPolicyUpdate.xml
as shown in the example below, replacing the contents within $$webtier..$$
with your web tier host and port IDs, and $$oam...$$
with the OAM host and administration server port as you did earlier:
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. NAME: UpdatePolicyRequest.xml - Template for updating application domain and/or policies without changes to any agent profile DESCRIPTION: Modify with specific values and pass file as input to the tool --> <PolicyRegRequest> <serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress> <hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier> <applicationDomainName>$$webtierhost$$_webcenter</applicationDomainName> </PolicyRegRequest>
Run the following command:
<RREG_Home>/bin/oamreg.sh policyUpdate input/WebCenterOAM11gPolicyUpdate.xml
Enter your OAM credentials when prompted. Enter yes
when asked whether you want to import a URIs file, and specify <RREG_HOME>/input/soa.oam.conf
.
Your policy will be updated with SOA resources.
Run the policyUpdate
command again, this time specifying <RREG_HOME>/input/oam.conf
to update the policy with Content Server resources. Your policy now contains Oracle WebCenter Portal, SOA and Content Server artifacts.
From the OAM Console, you should now be able to see the following artifacts:
11g WebGate agent named $$webtierhost$$_webcenter
11g host identifier by the same name
an application domain with the same name containing authentication and authorization policies which in turn contain protected and public policies
Go to Application Domain> $$webtierhost$$_webcenter > Authentication Policies. You should be able to see the following policies:
Exclusion Scheme
Protected Resource Policy
Public Resource Policy
WebCenter REST Policy
Open the WebCenter REST Policy and make sure that the Authentication Scheme is set to BasicSessionlessScheme
or BasicScheme
.
Open the Resources tab and search for resources with their Authentication Policy set to Exclusion Scheme
. You should see the following resources:
/rsscrawl*
/rsscrawl/.../*
/sesUserAuth*
/sesUserAuth/.../*
/services-producer/portlets*
/services-producer/portlets/.../*
/wsrp-tools/portlets
/wsrp-tools/portlets/.../*
Select the /rsscrawl*
resource in the search results and click Edit.
Change the Protection Level from Protected
to Excluded
and click Apply. Note that the resource's authentication policy and authorization policy is removed.
Close the Resources tab and repeat the steps for the remaining Exclusion Scheme
resources.
When you now search for resources with their Authentication Policy set to Exclusion Scheme
you should see no results.
Restart OHS.
After installing and configuring the web tier and associated components, continue by configuring the Policy Manager as described in Configuring the WebLogic Domain for OAM, and performing any additional service and component configurations that apply as described in Additional Single Sign-on Configurations.
If your environment spans multiple domains (for example, a domain for WebCenter Portal, a separate domain for SOA, and a separate domain for Content Server), repeat the steps in this section for each domain.
This section includes the following subsections:
Assuming Oracle Internet Directory is backing the OAM identity store, an Oracle Internet Directory authenticator (OracleInternetDirectoryAuthenticator
) should be configured for the LDAP server that is used as the identity store of OAM, and the provider should be set to SUFFICIENT
.
To configure the Oracle Internet Directory authenticator:
An OAM identity asserter must be configured with the provider Control Flag set to REQUIRED
.
To configure the OAM Identity asserter:
After configuring the OAM identity asserter, ensure that the default authenticator's control flag is set to SUFFICIENT
and reorder the providers as shown below:
This step should be performed after installing and configuring OAM, and before configuring the WebLogic domain.
To install and configure the Oracle HTTP server (OHS).
The configurations described in the following sections may be necessary or helpful in providing additional security for your site. After completing these configurations, continue by testing your OAM installation as described in Testing Your OAM Installation.
Configure the WebCenter Portal application for SSO by adding a setting to EXTRA_JAVA_PROPERTIES
.
There is a system property that tells WebCenter Portal and ADF that the application is configured in SSO mode and some special handling is required. The following system property is required in this mode:
Field | Value | Comment |
---|---|---|
|
|
This flag tells WebCenter Portal that SSO is being used, so no login form should be displayed on the default landing page. Instead, it displays a login link that the user can click to invoke the SSO authentication. |
To set this property, edit the setDomainEnv.sh
script located in your <domain>/bin
directory, and add an entry like the following:
EXTRA_JAVA_PROPERTIES="-Doracle.webcenter.spaces.osso=true ${EXTRA_JAVA_PROPERTIES}" export EXTRA_JAVA_PROPERTIES
After making this change, restart the WC_Portal
server.
This section describes how to configure the discussions server for single sign-on. Before configuring the discussions server for SSO, ensure that it has been configured to use the same identity store LDAP as WebCenter Portal, as described in Reassociating the Identity Store with an External LDAP Server. If you've chosen not to move the default administrator account to an external LDAP, be sure to also follow the instructions in Migrating the Discussions Server to Use an External LDAP.
Note:
Direct login to the discussions server is not supported after SSO is configured. Log in must be done through the Oracle HTTP Server URL.
To set up the discussions server for SSO:
This section describes how to update the discussions server connection for WebCenter Portal so that it uses the web tier's host and port values. Note that the steps below assume that the discussions component has already been installed and configured in the WebCenter Portal domain.
Assuming that you've already set up a SOA server connection, modify the URL to use the web tier host and port instead of the SOA server host and port. You can do this using Fusion Middleware Control as described in Specifying the BPEL Server Hosting WebCenter Portal Workflows.
After modifying the URL and completing the setup required for OAM SSO, run the following command on the WebCenter Portal Administration server so that the changes take effect:
setBPELConnection('webcenter','WebCenter-Worklist', 'http://webtier.example.com:7777')
By default, WebCenter Portal RSS feeds are protected by SSO. However, they will not work well with external readers if left protected. If access using external readers is important, Oracle recommends that the WebCenter Portal RSS resource be excluded from the OAM policy so that the authentication for the RSS Servlet is handled by WebLogic Server's BASIC authentication that external readers can handle.
Follow the steps below to unprotect RSS feed for OAM 11g:
This section describes how to optionally set up OAM 11g single sign-on for the WebLogic Server Administration Console and Enterprise Manager.
Note:
Setting up OAM SSO for Enterprise Manager and the WebLogic Server Administration Console would provide single sign-on access to same set of users for whom OAM SSO access has been configured. If want the web tier to be accessible to external users through OAM, but want administrators to log in directly to Enterprise Manager and the WebLogic Server Administration Console, then you may not want to complete this additional configuration step.
To set up OAM 11g SSO for the WebLogic Server Administration Console and Enterprise Manager:
Log in to the OAM Console using your browser:
http://host:port/oamconsole
Go to Policy Configuration > Application Domains.
The Policy Manager pane displays.
Locate the application domain you created using the name while registering webgate agent.
Expand the Resources node and click Create.
The Resource page displays.
Add the resources that must be secured. For each resource:
Select http
as the Resource Type.
Select the Host Identifier created while registering the WebGate agent.
Enter the Resource URL for the WebLogic Server Administration Console (/console
) or Enterprise Manager (/em
).
Enter a Description for the resource and click Apply.
Go to Authentication Policies > Protected Resource Policy and add the newly created resource.
Do the same under Authorization Policies > Protected Resource Policy>
In your web tier, modify the mod_wl_ohs.conf
file (in WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/
) to include the WebLogic Server Administration Console and Enterprise Manager, by adding two additional Location entries using the actual host ID for the WebCenter Portal Administration Server for WebLogicHost
.
<Location /console> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 7001 </Location> <Location /em> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 7001 </Location>
Restart the Oracle HTTP Server for your changes to take effect.
You should now be able to access the WebLogic Server Administration Console and Enterprise Manager with the following links:
http://host:OHS port/console http://host:OHS port/em
and be prompted with the OAM SSO login form.
The crawl sources that are defined to crawl WebCenter Portal data and repositories used by WebCenter Portal and the corresponding authentication end points defined in SES must be routed through the web tier OHS ports so that they can be properly authenticated (the authentication method continues to be BASIC and realm jazn.com). For information about configuring SES connections, see Setting Up Oracle SES Connections.
After you've completed your SSO setup, and after setting up a connection for Content Server, specify the web context root in the JCRContentServerConnection
using Fusion Middleware Control, or as shown in the following WLST example:
setJCRContentServerConnection(appName, name, webContextRoot='/cs')
Setting the web context root tells the Document Library code that SSO has been set up. Note that this setting should not be set until after SSO has been completely set up.
Follow the steps below to only allow users to access WebCenter Portal and associated components through the web tier OHS ports so that they can be properly authenticated.
If you have set up your Portlet Producer applications to route through OHS, be sure to use the OHS host and port when specifying producer URLs for registration. This applies to out of-the-box producers like wsrp-tools, services-producer, pagelet producers and any other producer you have explicitly configured.
After installing and configuring OAM 11g, check that you can access all of the configured applications below (as they apply to your environment), and that the global login and logout is giving you access to all of your configured applications without prompting you to sign in again. Also test global logout where available and make sure you are logged out of all other related applications.
WebCenter Portal: Access any protected WebCenter Portal URL (a protected portal, for example), and make sure that you see the SSO login challenge. If you are already logged into another related application that uses the same SSO, you should automatically be shown content.
REST: Access http://ohshost:ohsport/rest/api/resourceIndex
. You should see the BASIC authentication challenge. If you are already logged into another related application that uses the same SSO, you should automatically be shown content.
REST: Access http://ohshost:ohsport/rest/api/cmis/....
(retrieve this from resourceIndex
access output in the previous step). You should not see a login challenge and should be able to see public content. When you access this after you've logged in, then you should see all content to which you have access rights.
Content Server: Go to the profile UI and check that you can see Content Server screens embedded in iFrames without challenging you to log in. You should also be able to access Site Studio content in Content Presenter templates without logging in as you are already logged into WebCenter Portal.
SOA: Access links in a workflow task flow and make sure that you are not challenged to log in.
Discussion forums: Access the discussions application at http://host:port/owc_discussions
and log in. Check that the login is the SSO login challenge. Similarly, the Administration login to the discussions server at http://host:port/owc_discussions/admin
should also go through the SSO login challenge.
Security Assertion Markup Language (SAML) enables cross-platform authentication between web-based applications or web services running in a WebLogic Server domain, and web browsers or other HTTP clients. WebLogic Server supports single sign-on (SSO) based on SAML for WebCenter Portal (Pagelet Producer applications are not supported).
When users are authenticated at one site that participates in a single sign-on configuration, they are automatically authenticated at other sites in the SSO configuration and do not need to log in separately. Note that since Pagelet Producer applications do not participate in SAML SSO, users are required to log in explicitly if they accesses the Pagelet Producer application.
Note:
Although SAML-based single sign-on provides support for logging users onto subsequent applications after initial sign-on, global logout is not supported. Consequently, users must log out of each individual application they open.
Note also that if you set up SAML-based single sign-on with WebCenter Portal as the source application and discussions as the destination application, administrators can access the discussions administration pages from WebCenter Portal Administration (Configuration > Services) and Portal Settings (Services page). However, since discussions administration pages do not participate in SSO, if you access administration pages directly, you are required to log in to the discussions server again.
Finally, SAML-based single sign-on is not available for the sdpmessaging
userprefs-ui
application. As an application administrator, if you click Manage Configuration in the Preferences > Messaging dialog in WebCenter Portal, you will need to log in again.
This SSO mechanism can be used for departmental installations for which there is no existing Oracle SSO or Oracle Access Manager single sign-on infrastructure, but single sign-on between only WebCenter Portal and its components or services is required. For High Availability and large enterprise deployments, Oracle Access Manager SSO is recommended.
This section describes how to set up SAML 1.1-based single sign-on for WebCenter Portal and SOA running on different managed servers within the same domain.
This section includes the following topics:
Figure 28-5 shows the components and their interaction in a SAML-based single sign-on configuration that includes WebCenter Portal and discussions.
A SAML-based single sign-on solution consists of the following components:
SAML Credential Mapper – The SAML Credential Mapping provider acts as a producer of SAML security assertions, allowing WebLogic Server to act as a source site for using SAML for single sign-on. The SAML Credential Mapping provider generates valid SAML 1.1 assertions for authenticated subjects based on the configuration of the target site or resource.
Inter Site Transfer Service (ITS) – an addressable component that generates identity assertions and transfers the user to the destination site.
Assertion Retrieval Service (ARS) – an addressable component that returns the SAML assertion that corresponds to the artifact. The assertion ID must have been allocated at the time assertion was generated.
SAML Identity Asserter – The SAML Identity Assertion provider acts as a consumer of SAML security assertions, allowing WebLogic Server to act as a destination site for using SAML for single sign-on. The SAML Identity Assertion provider processes valid SAML 1.1 assertions for authenticated subjects obtained from the source site or resource.
Assertion Consumer Service (ACS) – an addressable component that receives assertions and/or artifacts generated by the ITS and uses them to authenticate users at the destination site
SAML Relying party – A SAML Relying Party is an entity that relies on the information in a SAML assertion produced by the SAML source site. You can configure how WebLogic Server produces SAML assertions separately for each Relying Party or use the defaults established by the Federation Services source site configuration for producing assertion.
SAML Asserting party – A SAML Asserting Party is a trusted SAML Authority (an entity that can authoritatively assert security information in the form of SAML Assertions).
Figure 28-4 shows the components and flow for a POST-configured SAML SSO configuration that includes both a WebCenter Portal and SOA domain. The flow is similar for other destination applications participating in single sign-on such as and discussions.
Figure 28-4 Detailed SAML Single Sign-on Components and Topology (POST Profile Configured)
Figure 28-5 shows a simplified version of the components and flow for a POST-configured SAML SSO configuration, including the SAML SSO flow between WebCenter Portal and the discussions application.
Figure 28-5 SAML Single Sign-on Components and Topology (POST Profile Configured)
The steps in the flow are:
The user's browser accesses WebCenter Portal (source site), hosted on a WebLogic managed server (WC_Portal
) in the WebCenter Portal domain (wc_domain
), by supplying user credentials.
WebCenter Portal passes the user credentials to the authentication service provider.
If authentication is successful, the authenticated session is established, and the WebCenter Portal welcome page is displayed.
From the welcome page, the user then clicks on a link on the page to access a secured web page of the discussions destination site, hosted on a different WebLogic Server (WC_Collaboration
) in the same domain. This triggers a call to the Inter-Site Transfer Service (ITS) servlet configured. In this case, the ITS servlet is hosted within the source site (that is, on the WebCenter Portal application on the WC_Portal
managed server) that shares the same JSESSIONID cookie as WebCenter Portal.
The ITS servlet calls the SAML Credential Mapper configured in the WebCenter Portal domain (wc_domain
) to request a caller assertion. The SAML Credential Mapper returns the assertion. It also returns the URL of the destination site application Web page (a secured Web page for discussions) and path to the appropriate POST form (if the source site is configured to use the POST profile).
The SAML ITS servlet generates a SAML response containing the generated assertion, signs it, base-64 encodes it, embeds it in the HTML form, and returns the form to the user's browser.
The user's browser POSTs the form to the destination site's Assertion Consumer Service (ACS). In this case, the ACS Servlet is hosted in destination site (discussions) and shares its login cookie.
The assertion is validated.
If the assertion is successful, the user is redirected to the target (the secured Web page for discussions).
The user is logged in on the destination site (discussions) without having to reauthenticate.
This section describes how to configure WebCenter Portal and associated services and components for SAML-based single sign-on using a set of automated scripts.
This section includes the following topics:
This section describes a set of steps that should be carried out prior to configuring SAML-based single sign-on. Note that these steps assume that WebCenter Portal and associated components are already installed and the relevant connections have been configured and tested.
The prerequisites for SAML-based SSO are described in the following topics:
If your instance uses a Documents connection that requires the use of OHS to surface the Content Server user interface in WebCenter Portal, you need to configure WebCenter Portal and related applications with a web tier.
When configuring SAML SSO for a configuration that includes Content Server, all HTTP URLs should point to the web tier host and port. Additionally, when Content Server is front-ended with OHS, the following entries must appear in mod_wl_ohs.conf
, apart from the usual configuration for WebCenter Portal:
<Location /cs> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location> <Location /adfAuthentication> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location> <Location /samlacs/acs> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location>
See Installing and Configuring the Oracle HTTP Server for more information about installing OHS and editing mod_wl_ohs.conf
.
Additionally, when a custom login page is used for WebCenter Portal the following HTML comment must be added to the head section of the HTML page generated for Content Server for Site Studio Designer to work:
<!--IdcClientLoginForm=1-->
This HTML comment appears in the out-of-the-box log in pages in WebCenter Portal, but if you configure a new page to be the login page in a SAML SSO setup, then the comment must be added by hand, or in generated HTML as shown in the following example for a JSF page:
<af:document id="d1"> <f:facet name="metaContainer"> <f:verbatim> ${cb.commentText} </f:verbatim> </f:facet> .........
where cb
is a managed bean containing the method:
public String getCommentText(){ return "<!--IdcClientLoginForm=1-->"; }
After checking that the comment text is added verbatim in the metaContainer
facet of af:document
, check the generated HTML page using View Source and confirm that <!--IdcClientLoginForm=1-->
is in the <head>
section of the HTML page.
By default, the .EAR file that is deployed for the Oracle WebCenter Portal's Discussion Server Server supports form-based Oracle SSO or Oracle Access Manager SSO. Therefore, before you can configure the Oracle WebCenter Portal's Discussion Server for SAML-based single sign-on, you must also first deploy the SAML SSO version of the discussion server .EAR file.
Note:
Before configuring the discussions server for SSO, ensure that it is configured to use the same identity store LDAP as WebCenter Portal, as described in Reassociating the Identity Store with an External LDAP Server. If you've chosen not to move the default administrator account to an external LDAP, be sure to also follow the instructions in Migrating the Discussions Server to Use an External LDAP.
To deploy and configure the SAML SSO version of the Oracle WebCenter Portal's Discussion Server:
To secure communication between the SAML source and destination sites, communication should be encrypted. Additionally, certificates should be used to verify the identity of the other party during SAML interaction.
Using the getOpssService
, listKeyStoreAliases
, and exportKeyStoreCertificate
WLST commands, get and export the certificate you have chosen to use to encrypt SAML assertions as shown in the following example. Be sure to run the exportKeyStoreCertificate
command on the keystore that is configured for WC_Portal
and the Administration server for the WebCenter Portal domain. For more information, see Managing Keys and Certificates with the Keystore Service in Securing Applications with Oracle Platform Security Services . For syntax for these commands, see Keystore Service Command Reference in Securing Applications with Oracle Platform Security Services.
The following example demonstrates how to export DemoIdentity certificate, which is available in the demoidentity keystore configured for a weblogic server by default. Use this as a guideline to list and export the certificate from the keystore configured in your environment that you wish to use for SAML configuration.
connect()
svc = getOpssService(name='KeyStoreService')
svc.listKeyStoreAliases(appStripe="system", name="demoidentity", password='DemoIdentityKeyStorePassPhrase', type="*")
svc.exportKeyStoreCertificate(appStripe='system', name='demoidentity', password='DemoIdentityKeyStorePassPhrase', alias='DemoIdentity',
type='Certificate', filepath='/tmp/demoidentity.der'
Note:
The path used infilepath
above should match the certPath
value in wcsamlsso.properties
. Note also that the certificate must be exported only in PEM/DER format.If the WebCenter Portal installation requires SSL for providing transport-level security, then SSL should be configured before configuring single sign-on as described in Configuring SSL . Note that setting up SSL is not related to enabling SSO.
After installing WebCenter Portal and services and components as required for your environment, continue by configuring SAML-based single sign-on using the scripts as described in this section.
The scripts set up SAML-based single sign-on in a WebLogic environment by configuring:
SAML Credential Mapping Provider
Necessary relying parties
Source Site Federation Services
SAML Identity Asserter
Necessary asserting parties
Destination Site Federation Services
This section includes the following topics:
The single sign-on script to configure SAML 1.1 SSO for WebCenter Portal and related applications is located in the WCP_ORACLE_HOME/webcenter/scripts/samlsso
folder. The following files are relevant for SAML configuration:
wcsamlsso.properties
configureSpaces.py
configureCollab.py
configureUtilities.py
configureSOA.py
configureUCM.py
configureREST.py
configureForum.py
configureWorklistIntegration.py
configureCS.py
wcsamlsso.properties
This properties file (WCP_ORACLE_HOME/webcenter/scripts/samlsso/wcsamlsso.properties
) encapsulates the necessary configuration information for the SAML SSO setup. Copy the properties file to the WCP_ORACLE_HOME/common/bin
folder, change directories to that folder and edit wcsamlsso.properties
as described below before running the configuration scripts.
The properties file has the following sections:
spaces_config
This section captures the login information, WebLogic Admin URL, WebCenter Portal server and URL, and so forth, of the WebCenter Portal domain required for the Credential Mapper and Source Site Federation Services configuration. All properties in this section must be completed.
configFile
- Config file containing the weblogic user account and password for the WebCenter Portal domain
keyFile
- Key file to decrypt the weblogic user account and password for the WebCenter Portal domain
adminURL
- WebLogic Admin URL to connect to WLST
usesSSL
- Indicates whether WebCenter Portal is configured to use SSL
url
- WebCenter Portal URL. If usesSSL
is "true
", then change "http
" to "https
". If WebCenter Portal is front-ended with a web tier, then specify the web tier host and port here.
serverName
- Server where WebCenter Portal is deployed, typically WC_Collaboration
certAlias
- Alias of certificate to sign SAML assertions
certPassword
- Encrypted password of certificate to sign SAML assertions
collab_config
This section captures the login information, admin URL, certificate file path, and so forth, of the Collaboration domain required for the Identity Asserter and Destination Site Federation Services configuration. Only complete this section if your setup has discussions configured.
configFile
- Config file containing weblogic
user account and password for the Services domain
keyFile
- Key file to decrypt weblogic
user account and password for the Services domain
adminURL
- WebLogic Admin URL to connect to WLST
usesSSL
- Indicates whether discussions is configured to use SSL
serverName
- Server where discussions is deployed (typically the WC_Collaboration
managed server)
certAlias
- Alias of certificate to verify SAML assertions
certPath
- Path to exported certificate to verify SAML assertions. Note that the certificate path should be a valid path on the machine that hosts the domain (i.e., the one specified in adminURL
)
utilities_config
This section captures the login information, admin URL, and certificate file path of the Utilities domain required for the Identity Asserter and Destination Site Federation Services configuration. Complete this section out only if your setup is configured with the Activity Graph application.
configFile
- Configuration file containing weblogic
user account and password for the Utilities domain
keyFile
- Key file to decrypt weblogic
user account and password for the Utilities domain
adminURL
- WebLogic Admin URL to connect to WLST
usesSSL
- Indicates whether Utilities applications are configured to use SSL
serverName
- Server where Utilities applications are deployed (typically the WC_Utilities
managed server)
certAlias
- Alias of certificate to verify SAML assertions
certPath
- Path to exported certificate to verify SAML assertions. Note that the certificate path should be a valid path on the machine that hosts the domain (i.e., the one specified in adminURL
)
soa_config
This section captures the login information, admin URL, certificate file path, and so forth, of the SOA domain required for the Identity Asserter and Destination Site Federation Services configuration. Only complete this section if your setup has SOA configured.
configFile
- Configuration file containing the weblogic
user account and password for the SOA domain
keyFile
- Key file to decrypt the weblogic
user account and password for the SOA domain
adminURL
- WebLogic admin URL to connect to WLST
usesSSL
- Indicates whether SOA applications are configured to use SSL
serverName
- Server where SOA applications are deployed (typically soa_server1
)
certAlias
- Alias of certificate to verify SAML assertions
certPath
- Path to exported certificate to verify SAML assertions. Note that the certificate path should be a valid path on the machine that hosts the domain (i.e., the one specified in adminURL
)
ucm_config
This section captures the login information, admin URL, certificate file path, and so forth, of the Content Server domain required for the Identity Asserter and Destination Site Federation Services configuration. Only complete this section if your installation has the Documents service configured.
configFile
- Configuration file containing the weblogic user name and password for the Content Server (UCM) domain
usesSSL
- Indicates whether Content Server applications are configured to use SSL
keyFile
- Key File to decrypt the weblogic
user account and password for the Content Server (UCM) domain
adminURL
- WebLogic Administration URL to connect to WLST
serverName
- Server where Content Server applications are deployed (typically UCM_server1
)
certPath
- Path to exported certificate to verify SAML assertions. Note that the certificate path should be a valid path on the machine that hosts the domain (i.e., the one specified in adminURL
)
rss_config
This is mandatory
url
- RSS URL. If usesSSL
in spaces_config is "true
", then change "http
" to "https
". If RSS is front-ended with web tier, then specify the web tier host and port here.
rest_config
This section must be completed.
url
- REST URL. If usesSSL
in spaces_config is "true
", then change "http
" to "https
". If REST is front-ended with a web tier, then specify the web tier host and port here.
forum_config
Complete this section if your configuration has discussions installed.
url
- OWC discussions URL. If usesSSL
in collab_config is "true
", then change "http
" to "https
". If discussions is front-ended with a web tier, then specify the web tier host and port here.
worklist_config
Complete this section if SOA is installed and portal workflows is enabled for WebCenter Portal. For more information, see Specifying the BPEL Server Hosting WebCenter Portal Workflows.
worklist_integration
- Worklist Integration application URL. If usesSSL
in soa_config is "true
", then change "http
" to "https". If Worklist Detail application is front-ended with a web tier, then specify the web tier host and port here.
cs_config
Complete this section if your configuration has Content Server installed and you have a documents connection configured for the WebCenter Portal application.
url
- Content Server URL. If usesSSL
in spaces_config is "true
", then change "http
" to "https
". If Content Server is front-ended with a web tier, then specify the web tier host and port here. Note that if both WebCenter Portal and Content Server are configured for your environment, then they must both be accessed using the same web tier.
configureSpaces.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureSpaces.py
) to configure SAML 1.1 Credential Mapper, SAML 1.1 Identity Asserter and Source and Destination site federation services on the WebCenter Portal domain
configureCollab.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureCollab.py
) to configure SAML 1.1 Identity Asserter and Destination site federation services on the Collaboration domain
configureUtilities.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureUtilities.py
) to configure SAML 1.1 Identity Asserter and Destination site federation services on the Utilities domain
configureSOA.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureSOA.py
) to configure SAML 1.1 Identity Asserter and Destination site federation services on the SOA domain
configureUCM.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureUCM.py
) to configure SAML 1.1 Identity Asserter and Destination site federation services on the Content Server domain
configureREST.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureREST.py
) to configure asserting and relying parties for the REST application
configureRSS.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureRSS.p
y
) to configure asserting and relying parties for RSSapplication
configureForum.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureForum.p
y
) to configure asserting and relying parties for discussions
configureWorklistIntegration.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureWorklistIntegration.py
) to configure asserting and relying parties for the Worklist Integration application
configureWorklistDetail.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureWorklistDetail.py
) to configure asserting and relying parties for the Worklist Community Detail application
configureWorklistSDP.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureWorklistSDP.py
) to configure asserting and relying parties for the Worklist SDP application
configureCS.py
Executable script (WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureCS.py
) to configure asserting and relying parties for the Content Server application.
Follow the steps below to use the scripts to configure SAML-based single sign-on:
Note:
If you encounter errors when running the scripts due to configuration errors, the SAML SSO configuration may be left in an incomplete state. The configuration scripts provided are not re-runnable; you must clean up the SAML SSO artifacts before you retry the configuration as described in Removing Your SAML SSO Configuration.
Ensure that the Administration server for all the domains used in this configuration are up and running.
Generate the configuration and key files containing the connection information for the various domains using the storeUserConfig
WLST command from the WCP_ORACLE_HOME
/common/bin
so that the properties file is picked up. Use the command-line help (help('storeUserConfig'))
for usage and syntax details.
Connect using WLST to the WebCenter Portal domain using the admin username and password, and run the following command:
storeUserConfig('spacesconfig.secure', 'spaceskey.secure')
This creates a user configuration file and an associated key file. The user configuration file contains an encrypted username and password. The key file contains a secret key that is used to encrypt and decrypt the username and password. The above command stores the configuration and key files in the directory from where WLST was invoked, or you can optionally specify a more secure path.
Repeat step 2a after connecting to the Collaboration domain using the admin username and password. Even if the Utilities server is in the same domain as WebCenter Portal (wc_domain
), you must connect to the WebCenter Portal domain and run this command:
storeUserConfig('collabconfig.secure', 'collabkeykey.secure')
Repeat step 2a after connecting to the Utilities domain using the admin username and password. Even if the Utilities server is in the same domain as WebCenter Portal (wc_domain
), you must connect to the WebCenter Portal domain and run this command:
storeUserConfig('utilitiesconfig.secure', 'utilitieskey.secure')
Repeat step 2a after connecting to the SOA domain using the admin username and password. Even if SOA is installed on the same domain as WebCenter Portal, you must connect to the WebCenter Portal domain and run this command:
storeUserConfig('soaconfig.secure', 'soakey.secure')
Repeat step 2a after connecting to the Content Server domain using the admin username and password.
storeUserConfig('ucmconfig.secure', 'ucmkey.secure')
Launch WLST and run the WLST encrypt
command to encrypt the certificate password. Use the command-line help (help('encrypt')
) for usage and syntax details.
print encrypt(obj='<certificatePassword>', domainDir='<full path to the WebCenter Portal domain directory>')
This displays the encrypted certificate password. The encrypt command uses the encryption for a specified WebLogic Server domain root directory. The encrypted output needs to be set as the certPassword
value in wcsamlsso.properties
mentioned in the next step. Since this password will be set onto the credential mapper and source site federation services in the WebCenter Portal domain, ensure that you run the encryption utility from the WebCenter Portal domain.
Edit WCP_ORACLE_HOME
/common/bin/wcsamlsso.properties
and complete the sections applicable to your setup. Refer to The Single Sign-on Script for a detailed description of the sections in the properties file.
Launch WLST from WCP_ORACLE_HOME
/common/bin
and execute the scripts in the order shown below.
Note:
Run the scripts in the WLST offline mode as the scripts include an explicit connect command.
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureSpaces.py')
Restart all servers including the Administration server in the WebCenter Portal domain.
If you have a discussions server set up, execute the configureCollab.py
script:
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureCollab.py')
If discussions belongs to the same domain as WebCenter Portal, then only restart the WC_Collaboration
managed server. Otherwise, restart all servers including the Administration server in the Collaboration domain.
If you have a Utilities server set up, execute the configureUtilities.py
script:
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureUtilities.py')
If the Utilities server belongs to the same domain as WebCenter Portal, then only restart the WC_Utilities
server. Otherwise, restart all servers including the Administration server in the Utilities domain.
If you have SOA server connections configured for WebCenter Portal, execute the configureSOA.py
script:
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureSOA.py')
Restart all servers including the Administration server in the SOA domain.
If you have documents configured for WebCenter Portal, run the configureUCM.py
script as shown below:
execfile('WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureUCM.py')
Restart all servers including the Administration server in the Content Server domain.
Run the individual commands below as required for your environment.
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureREST.py')
- No restart is required.
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureRSS.py')
- No restart is required.
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureForum.py')
- Do this if you have discussions installed in your setup. No restart is required.
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureWorklistIntegration.py')
- Do this if you have Worklist installed in your setup. No restart is required.
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureWorklistDetail.py')
- Do this if you have Worklist installed in your setup. No restart is required.
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureWorklistSDP.py')
- Do this if you have Worklist installed in your setup. No restart is required.
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureCS.py')
- Do this if you have Content Server installed in your setup. No restart is required.
Check your installation using the steps provided in Checking Your Configuration.
Note:
Since the properties file contains sensitive information, delete it from <WCP_ORACLE_HOME>/common/bin
after you have configured and verified the SAML SSO setup. Also delete the config and key files you generated in step 2 above.
Note:
If you encounter errors when running the scripts, you must remove the asserting and relying parties set up by the scripts before running the scripts again as described in Removing Your SAML SSO Configuration.
After removing your old SAML SSO configuration, continue by re-running the scripts.
By default, WebCenter Portal RSS feeds are protected by SSO. However, they will not work well with external readers if left protected. If access using external readers is important, Oracle recommends that the WebCenter Portal RSS resource be unprotected so that the authentication for the RSS Servlet is handled by WebLogic Server's BASIC authentication that external readers can handle.
Follow the steps below to unprotect the RSS feeds:
Follow the steps below to check that your single sign-on configuration is working correctly.
To test your single sign-on configuration:
http://host:port/rest/api/resourceIndex
and make sure you see the BASIC authentication challenge. If you are already logged in to another related application that uses the same SSO, you should shown content without being challenged to log in.If while testing SAML SSO you encounter 404 or 403 errors, check the SAML configuration and also turn on debug logging for SAML on the AdminServer
. Also turn on logging for the WC_Portal
server and the server hosting your destination site. The logs will be available in $domain.home/servers/<server>/logs/<server>.log
. For information on how to turn on logging for WC_Portal
and other application servers, see Viewing and Configuring WebCenter Portal Logs. Before re-running the scripts, remove your SAML SSO configuration as described in Removing Your SAML SSO Configuration.
This section describes how to temporarily disable your SAML SSO configuration for testing or other purposes.
To disable your SAML SSO configuration:
Log onto the WLS Administration Console for the WebCenter Portal domain.
Open the security realm and select Providers >Credential Mapping > wcsamlcm> Management > Relying Parties and disable all the relying parties shown there.
Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties and disable all the asserting parties shown there.
If there are other WLS domains, such as SOA or Content Server, that have been configured with SAML SSO, remove the SAML SSO configuration from these domains as well:
Log in to the WLS Administration Console for the WLS domain.
Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties and disable all the asserting parties shown there.
Confirm that the SAML SSO configuration has been disable by opening your applications and checking that you are not prompted to sign in.
Since the SAML SSO configuration scripts do not include a cleanup facility, if you have made errors while updating the wcsamlsso.properties
file or running the scripts, the configuration could be in an invalid state. At this point, it's better to clean up all the SAML SSO configurations and start over. This section describes the steps to remove the SAML SSO configuration.
Note that if you have fully set up SAML SSO (i.e., the script ran to completion), then all the instructions below will be valid. However, if you encountered errors while running the script, then the configuration may be incomplete and only some of the artifacts below will be present and will need to be removed.
To remove your SAML SSO configuration:
Log onto the WLS Administration Console for the WebCenter Portal domain.
Open the security realm and select Providers >Credential Mapping > wcsamlcm> Management > Relying Parties and delete all the relying parties shown there.
Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties and delete all the asserting parties shown there.
Go to Providers > Authentication > wcsamlia > Management > Certificates and delete the certificate there.
Go to Providers > Credential Mapping > wcsamlcm and delete the SAML Credential Mapper.
Go to Providers > Authentication > wcsamlia and delete the SAML Identity Asserter.
Restart the entire WebCenter Portal WLS domain.
If there are other WLS domains, such as SOA or Content Server, that have been configured with SAML SSO, remove the SAML SSO configuration from these domains as well:
Log in to the WLS Administration Console for the WLS domain.
Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties and delete all the asserting parties shown there.
Go to Providers > Authentication > wcsamlia > Management > Certificates and delete the certificate there.
Go to Providers > Authentication > wcsamlia and delete the SAML Identity Asserter.
Restart the entire WLS domain.
Confirm that the SAML SSO configuration has been removed by opening your applications and checking that you are not prompted to sign in. You can now safely use the scripts again to reconfigure SAML SSO.
This section describes how to set up single sign-on (SSO) for Microsoft clients, using Windows authentication based on the Simple and Protected Negotiate (SPNEGO) mechanism and the Kerberos protocol, together with the WebLogic Negotiate Identity Assertion provider for WebCenter Portal. This SSO approach enables Microsoft clients (such as browsers), authenticated in a Windows domain using Kerberos, to be transparently authenticated to web applications (such as WebCenter Portal) in a WebLogic domain based on the same credentials, and without the need to type in their password again. For more information about using Microsoft Office clients with WebCenter Portal, see Chapter 25, "Managing Microsoft Office Integration."
Cross-platform authentication is achieved by emulating the negotiate behavior of native Windows-to-Windows authentication services that use the Kerberos protocol. In order for cross-platform authentication to work, non-Windows servers (in this case, WebLogic Server) must parse SPNEGO tokens in order to extract Kerberos tokens, which are then used for authentication.
This section contains the following subsections:
Understanding Kerberos
Kerberos is a secure method for authenticating a request for a service in a network. The Kerberos protocol comprises three parties: a client, a server and a trusted third party to mediate between them, known as the KDC (Key Distribution Center). Under Kerberos, a server allows a user to access its service if the user can provide the server a Kerberos ticket that proves its identity. Both the user and the service are required to have keys registered with the KDC.
The diagram below describes the basic exchanges that must take place before a client connects to a server.
Figure 28-6 Connecting to a Server Through a Key Distribution Center
Understanding SPNEGO
SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is a GSSAPI "pseudo mechanism" that is used to negotiate one of several possible real mechanisms. SPNEGO is used when a client application wants to authenticate to a remote server, but neither end is sure what authentication protocols the other supports. The pseudo-mechanism uses a protocol to determine what common GSSAPI mechanisms are available, selects one, and then dispatches all further security operations to it. This can help organizations deploy new security mechanisms in a phased manner.
SPNEGO's most visible use is in Microsoft's HTTP Negotiate authentication extension. The negotiable submechanisms include NTLM and Kerberos, both used in Active Directory.
This feature enables a client browser to access a protected resource on WebLogic Server, and to transparently provide the WebLogic Server with authentication information from the Kerberos database using a SPNEGO ticket. The WebLogic Server can recognize the ticket and extract the information from it. WebLogic Server then uses the information for authentication and grants access to the resource if the authenticated user is authorized to access it. (Kerberos is responsible for authentication only; authorization is still handled by WebLogic Server.)
To use SSO with Microsoft clients you need:
A host computer with:
Windows 2000 or later installed
Fully-configured Active Directory authentication service. Specific Active Directory requirements include:
User accounts for mapping Kerberos services
Service Principal Names (SPNs) for those accounts
Key tab files created and copied to the start-up directory in the WebLogic Server domain
WebLogic Server installed and configured properly to authenticate through Kerberos, as described in this section
Client systems with:
Windows 2000 Professional SP2 or later installed
One of the following types of clients:
A properly configured Internet Explorer browser. Internet Explorer 6.01 or later is supported.
.NET Framework 1.1 and a properly configured Web service client.
Note:
Clients must be logged on to a Windows 2000 domain and have Kerberos credentials acquired from the Active Directory server in the domain. Local logins will not work.
Configuring SSO with Microsoft clients requires configuring the Microsoft Active Directory, the Microsoft client, and the WebLogic Server domain shown in Figure 28-8 . For detailed configuration steps and troubleshooting, see Configuring Single Sign-On with Microsoft Clients in Administering Security for Oracle WebLogic Server 12c (12.2.1).
Figure 28-8 Configuring SSO with Microsoft Clients
To configure Microsoft clients for SSO:
Configure your network domain to use Kerberos.
Create a Kerberos identification for WebLogic Server.
Create a user account in the Active Directory for the host on which WebLogic Server is running.
Create a Service Principal Name for this account.
Create a user mapping and keytab file for this account (see Configuring Single Sign-On with Microsoft Clients in Administering Security for Oracle WebLogic Server 12c (12.2.1)).
Choose a browser client (Internet Explorer or Mozilla Firefox) and configure it to use Kerberos tokens (see “Enabling the Browser to Return Kerberos Tokens” in Oracle Argus Insight Installation Guide).
Set up the WebLogic Server domain (wc_domain
in this case) to use Kerberos authentication.
Create a JAAS login file that points to the Active Directory server in the Microsoft domain and the keytab file created in Step 2 (see the "Creating a JAAS Login File in Administering Security for Oracle WebLogic Server 12c (12.2.1)).
Configure a Negotiate Identity Assertion provider in the WebLogic Server security realm (see Configuring the Negotiate Identity Assertion Provider).
Configure the WebLogic Server domain to use the Active Directory Authenticator so that the WebLogic domain uses the same Active Directory of the domain as the identity store. You could also use a different identity store and match the users in this store with the Active Directory users of your domain, but using the Active Directory authenticator is recommended as maintaining two different identity stores risks them getting out of sync (see Configuring an Active Directory Authentication Provider).
Caution:
Ensure that only the identity store is configured for Active Directory. The policy and credential stores are not certified for Active Directory.
Add the following system properties to the JAVA_OPTIONS
in setDomainEnv.sh
for each WebCenter Portal machine, changing the values below for the values of the particular host (on one line):
-Dnon_sso_protocol=http (the protocol to access WebCenter Portal directly through the WC_Portal server without going through OHS) -Dnon_sso_host=example.com (the host for the WLS WC_Portal server) -Dnon_sso_port=8888 (the port for the WLS WC_Portal server) -Dsso_base_url=http://example.com:7777 (the URL for accessing the WC_Portal server through OHS)
The non_sso
values are the value on the machine for protocol, host, and port. The sso
values are the value that the user would see when directed through OHS.
For WebCenter Portal, configure the web tier OHS so that it forwards requests to the Oracle WebLogic Server for WebCenter Portal, as described in Configuring SSO with Virtual Hosts.
Restart the WebLogic Servers (Administration Server and managed servers) using the startup arguments specified in step 5. Repeat steps 4, 5, and 6 for the SOA domain to enable single sign-on for SOA applications.
Restart the OHS for the changes to take effect.
Configure the discussions server (see Configuring the Discussions Server for SSO).
This section provides instructions for creating and configuring a Negotiate Identity Assertion provider. The Negotiate Identity Assertion provider enables single sign-on (SSO) with Microsoft clients. The identity assertion provider decodes Simple and Protected Negotiate (SPNEGO) tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps them to WebLogic users. The Negotiate Identity Assertion provider uses the Java Generic Security Service (GSS) Application Programming Interface (API) to accept the GSS security context through Kerberos.
To configure the Negotiate Identity Assertion provider:
Follow the steps below to configure an Active Directory authentication provider using the WebLogic Administration Console.
To configure an Active Directory Authentication provider:
Log in to the WebLogic Server Administration Console.
For information on logging in to the WebLogic Server Administration Console, see Oracle WebLogic Server Administration Console.
From the Domain Structure pane, click Security Realms.
The Summary of Security Realms pane displays.
Click your security realm.
The Settings page for the security realm displays.
Open the Providers tab and select the Authentication subtab.
The Authentication Settings pane displays.
Click New.
The Create a New Authentication Provider pane displays.
Enter a Name for the authentication provider, and select ActiveDirectoryAuthenticator
as the Type.
Click OK.
Click the authentication provider you just created in the list of providers.
The Settings page for the provider displays.
Open the Configuration tab and the Common subtab.
Set the Control Flag to SUFFICIENT
and click Save.
Note:
The Control Flag settings of any other authenticators must also be changed to SUFFICIENT
. If there is a pre-existing Default Authenticator that has its Control Flag set to REQUIRED
, it must be changed to SUFFICIENT
.
Open the Provider Specific subtab.
The Provider Specific Settings pane displays.
Complete the fields as shown in the table below. Leave the rest of the fields set to their default values.
Table 28-2 Active Directory Authenticator Settings
Parameter | Value | Description |
---|---|---|
Host: |
The host ID of the LDAP server |
|
Port: |
The port number of the LDAP server |
|
Principal: |
The LDAP administrator principal |
|
Credential: |
||
User Base DN: |
The user search base (for example, OU=spnego unit,DC=admin,DC=oracle,DC=com) |
|
User From Name Filter: |
(&(cn=%u)(objectclass=user)) |
|
User Search Scope: |
subtree |
|
User Name Attribute: |
cn |
|
User Search Scope: |
user |
|
Group Base DN: |
The group search base (same as User Base DN) |
|
Group From Name Filter: |
(&(cn=%g)(objectclass=group)) |
|
Group Search Scope: |
subtree |
|
Static Group Name Attribute: |
cn |
|
Static Group Object Class: |
group |
|
Static Member DN Attribute: |
member |
|
Static Group DNs from Member DN Filter: |
(&(member=%M)(objectclass=group)) |
Click Save.
On the Provider Summary page, reorder the providers in the following order, making sure that their Control Flags are set to SUFFICIENT
where applicable:
Negotiate Identity Asserter
ActiveDirectoryAuthenticator (SUFFICIENT
)
DefaultAuthenticator (SUFFICIENT
)
Other authenticators...
Once you have completed the steps for configuring the Negotiate Identity Assertion Provider and Active Directory Authenticator, and all applications on your WebLogic domain are configured for single sign-on with Microsoft clients in the required domain, a final step is required to provide a seamless single-sign-on experience for your users when accessing WebCenter Portal. There are two options for doing this:
Turn off public access, by logging in to WebCenter Portal as an administrator and removing View
access from the Public-User
role. When public access is turned off, accessing the URL http://host:port/webcenter
takes the user directly to the authenticated view rather than the default public page which has a login section. This is recommended when users are accessing WebCenter Portal only using Internet Explorer, and are confined to the domain where WNA is set up.
If you must retain public access to WebCenter Portal, then the recommendation is to use the oracle.webcenter.spaces.osso=true
flag when starting the WC_Portal
server. This flag tells WebCenter Portal that SSO is being used and no login form should be displayed on the default landing page. A Login link is displayed instead that the user can click to invoke the SSO authentication where the user will be automatically logged in. If Firefox is used to access WebCenter Portal within the Windows network configured for WNA, or any browser is used to access WebCenter Portal from outside the Windows network domain, users see the login page after clicking the Login link.
This section describes how to configure the discussions server for single sign-on. Before configuring the discussions server for SSO, ensure that it has been configured to use the same identity store LDAP as WebCenter Portal, as described in Migrating the Discussions Server to Use an External LDAP.
To set up the discussions server for SSO:
This section describes the OHS configuration required for an environment containing applications that use "/" as the context root, and the additional configuration required in OHS when single sign-on is involved.
This section contains the following subsections:
The term virtual host refers to the practice of running more than one web site (such as www.company1.com
and www.company2.com
) on a single machine. Virtual hosts can be IP-based, meaning that you have a different IP address for each web site, or name-based, meaning that you have multiple names running on each IP address. The fact that they are running on the same physical server is not apparent to the end user. For more information about virtual hosts, refer to your Apache documentation.
To configure OAM 11g for virtual hosts requires bypassing single sign-on for applications that only support BASIC authorization or do not require single sign-on.
Prior to completing these steps you should already have completed the steps for configuring OAM 11g in Configuring Oracle Access Manager.
Follow the steps below to configure virtual hosts for OAM 11g.
Locate and comment out the following configuration in webgate.conf
:
#Comment out this and move to VirtualHost configuration #<LocationMatch "/*"> #AuthType Oblix #require valid-user #</LocationMatch>
This entry causes the WebGate to intercept all requests and process it.
Move this entry into the virtual host configuration in httpd.conf
where single sign-on is required. as shown in the example below:
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName webtier.example.com <LocationMatch "/*"> AuthType Oblix require valid-user </LocationMatch> </VirtualHost> <VirtualHost *:7777> ServerName webtier-spaces.example.com <Location /> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /webcenter> Deny from all </Location> <Location /webcenterhelp> Deny from all </Location> <Location /rest> Deny from all </Location> </VirtualHost>
The idea is to provide a single sign-on experience for the default virtual host (webtier.example.com
), but not for the WebCenter Portal virtual host (webtier-spaces.example.com
) as some applications do not support it.
Restart OHS. Also be sure to update the DNS with entries for webtier-spaces.example.com
.
Note:
In the webtier-spaces.example.com
virtual host that bypasses single sign-on, only some applications need to bypass single sign-on. For other applications like WebCenter Portal, however, we need single sign-on so we deny access to these applications from this virtual host.