This chapter describes how to integrate Oracle WebCenter with Oracle Identity Management. It contains the following sections:
The following topics describe credential and policy store configuration in detail:
Oracle Fusion Middleware allows using different types of credential and policy stores in a WebLogic domain. Domains can use stores based on an XML file or on different types of LDAP providers. When a domain uses an LDAP store, all policy and credential data is kept and maintained in a centralized store. However, when using XML policy stores, the changes made on Managed Servers are not propagated to the Administration Server unless they use the same domain home. The Oracle Fusion Middleware WebCenter EDG topology uses different domain homes for the Administration Server and the Managed Server, thus Oracle requires the use of an LDAP store as policy and credential store for integrity and consistency. By default Oracle WebLogic Server domains use an XML file for the policy store. The following sections describe the steps required to change the default store to Oracle Internet Directory LDAP for credentials or policies.
Note:
The backend repository for the policy store and the credential store must use the same kind of LDAP server. To preserve this coherence, note that reassociating one store implies reassociating the other one, that is, the reassociation of both the credential and the policy stores is accomplished as a unit using the Fusion Middleware Control or the WLST commandreassociateSecurityStore
. For more information, see Section 10.1.4, "Reassociation of Credentials and Policies."A credential store is a repository of security data (credentials). A credential can hold user name and password combinations, tickets, or public key certificates. Credentials are used during authentication, when principals are populated in subjects, and, further, during authorization, when determining what actions the subject can perform. In this section, steps are provided to configure Oracle Internet Directory LDAP as a credential store for the Oracle Fusion Middleware WebCenter EDG topology. For more details on credential store configuration, refer to the "Configuring the Credential Store" chapter in the Oracle Fusion Middleware Security Guide.
The following section describe credential store configuration:
Section 10.1.2.2, "Moving the WebLogic Administrator to LDAP"
Section 10.1.2.3, "Reassociating the Domain Credential Store"
To be safe, before you create the LDAP authenticator, you should first back up the relevant configuration files:
ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/config/config.xml ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/config/fmwconfig/jps-config.xml ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/config/fmwconfig/system-jazn-data.xml
Also back up the boot.properties
file for the Administration Server.
To configure the credential store to use LDAP, set the proper authenticator using the WebLogic Server Console:
Log in to the WebLogic Server Console.
Click the Security Realms link on the left navigational bar.
Click the myrealm default realm entry to configure it.
Open the Providers tab within the realm.
Observe that there is a DefaultAuthenticator
provider configured for the realm.
Click the New button to add a new provider.
Enter a name for the provider such as OIDAuthenticator or OVDAuthenticator depending on whether Oracle Internet Directory or Oracle Virtual Directory will be used.
Select the OracleInternetDirectoryAuthenticator or OracleVirtualDirectoryAuthenticator type from the list of authenticators depending on whether Oracle Internet Directory or Oracle Virtual Directory will be used.
Click OK.
In the Providers screen, click the newly created Authenticator.
Set the control flag to SUFFICIENT. This indicates that if a user can be authenticated successfully by this authenticator, then it should accept that authentication and should not continue to invoke any additional authenticators. If the authentication fails, it will fall through to the next authenticator in the chain. Make sure all subsequent authenticators also have their control flag set to SUFFICIENT; in particular, check the DefaultAuthenticator and set that to SUFFICIENT.
Click Save to save this setting.
Open the Provider Specific tab to enter the details for the LDAP server.
Enter the details specific to your LDAP server, as shown in the following table:
Parameter | Value | Value Description |
---|---|---|
Host | For example: oid.mycompany.com |
The LDAP server's server ID. |
Port | For example: 636 |
The LDAP server's port number. |
Principal | For example: cn=orcladmin |
The LDAP user DN used to connect to the LDAP server. |
Credential | NA | The password used to connect to the LDAP server |
SSL Enabled | Checked | Specifies whether SSL protocol is used when connecting to LDAP server. |
User Base DN | For example: cn=users,dc=us,dc=mycompany,dc=com |
Specify the DN under which your Users start. |
Group Base DN | For example: cn=groups,dc=us,dc=mycompany,dc=com |
Specify the DN that points to your Groups node. |
Use Retrieved User Name as Principal | Checked | Must be turned on. |
Click Save when done.
Click Activate Changes to propagate the changes.
Before moving the WebLogic Administrator from defaultProvider to OID LDAP or External LDAP, follow these steps:
Identify which user on OID LDAP or external LDAP server (fmwadmin) will be assigned administrator privileges in Jive.
Once you have identified the user, go to the Weblogic Console and add this user to the security default provider.
Go to Jive Administration Console and log in as the WebLogic admin user in emdedded LDAP, and add the user (fmwadmin) as the administrator for Jive.
Reorder the OID/OVD Authenticator and Default Authenticator and ensure that the control flag for each authenticator is set as follows:
OID LDAP Authenticator: SUFFICIENT
Default Authenticator: SUFFICIENT
Restart the Administration Server so that the changes are effective, as follows:
Stop the Administration Server:
SOAHOST1> cd ORACLE_BASE/admin/domainName/aserver/domainName/bin SOAHOST1> ./stopWebLogic.sh
Start the Administration Server:
SOAHOST1> ./startWebLogic.sh
Note:
The reassociation of both the credential and the policy stores is accomplished as a unit using Fusion Middleware Control or the WLST commandreassociateSecurityStore
.
For more details on credential store configuration, refer to the "Configuring the Credential Store" chapter in the Oracle Fusion Middleware Security Guide.
This section provides details for provisioning a new administrator user and group for managing the Oracle Fusion Middleware WebCenter WebLogic Domain. This section describes the following tasks:
Section 10.1.2.2.1, "Provisioning Admin Users and Groups in an LDAP Directory"
Section 10.1.2.2.2, "Assigning the Admin Role to the Admin Group"
Section 10.1.2.2.3, "Updating the boot.properties File and Restarting the System"
As mentioned in the introduction to this section, users and groups from multiple WebLogic domains may be provisioned in a central LDAP user store. In such a case, there is a possibility that one WebLogic admin user may have access to all the domains within an enterprise. This is not a desirable situation. To avoid this, the users and groups provisioned must have a unique distinguished name within the directory tree. In this guide, the admin user and group for the WebCenter EDG WebLogic domain will be provisioned with the DNs below:
Admin User DN:
cn=weblogic_wc,cn=Users,dc=us,dc=mycompany,dc=com
Admin Group DN:
cn=WC_Administrators,cn=Groups,dc=us,dc=mycompany,dc=com
Follow these steps to provision the admin user and admin group in Oracle Internet Directory:
Create an ldif file named admin_user.ldif
with the contents shown below and then save the file:
dn: cn=weblogic_wc, cn=Users, dc=us, dc=mycompany, dc=com orclsamaccountname: weblogic_wc givenname: weblogic_wc sn: weblogic_wc userpassword: Welcome1 obver: 10.1.4.0 mail: weblogic_wc objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson objectclass: orcluser objectclass: orcluserV2 objectclass: oblixorgperson uid: weblogic_wc cn: weblogic_wc description: Admin User for the IDM Domain
Run the ldapadd
command located under the ORACLE_HOME/bin
directory to provision the user in Oracle Internet Directory.
Note:
The ORACLE_HOME used here is the ORACLE_HOME for the Identity Management installation where Oracle Internet Directory resides.For example (the command is shown as two lines in the example below for readability purposes, but you should enter the command on a single line):
OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D
cn="orcladmin" -w welcome1 -c -v -f admin_user.ldif
Create an ldif file named admin_group.ldif
with the contents shown below and then save the file:
dn: cn=WC_Administrators, cn=Groups, dc=us, dc=mycompany, dc=com displayname: WC_Administrators objectclass: top objectclass: groupOfUniqueNames objectclass: orclGroup uniquemember: cn=weblogic_wc,cn=users,dc=us,dc=mycompany,dc=com cn: WC_Administrators description: Administrators Group for the SOA Domain
Run the ldapadd
command located under the ORACLE_HOME/bin/
directory to provision the group in Oracle Internet Directory (the command is shown as two lines in the example below for readability purposes, but you should enter the command on a single line):
OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D
cn="orcladmin" -w welcome1 -c -v -f admin_group.ldif
After adding the users and groups to Oracle Internet Directory, the group must be assigned the Admin role within the WebLogic domain security realm. This enables all users that belong to the group to be administrators for that domain. Follow these steps tassign the Admin role to the Admin group:
Log into the WebLogic Administration Server Console.
In the left pane of the console, click Security Realms.
On the Summary of Security Realms page, click myrealm under the Realms table.
On the Settings page for myrealm, click the Roles & Policies tab.
On the Realm Roles page, expand the Global Roles entry under the Roles table. This brings up the entry for Roles. Click on the Roles link to bring up the Global Roles page.
On the Global Roles page, click the Admin Role to bring up the Edit Global Role page:
On the Edit Global Roles page, under the Role Conditions table, click the Add Conditions button.
On the Choose a Predicate page, select Group from the drop down list for predicates and click Next.
On the Edit Arguments Page, specify WC_Administrators in the Group Argument field and click Add.
Click Finish to return to the Edit Global Rule page.
The Role Conditions table now shows the WC_Administrators Group as an entry.
Click Save to finish adding the Admin Role to the WC_Administrators Group.
Validate that the changes were successful by bringing up the WebLogic Administration Server Console using a web browser. Log in using the credentials for the weblogic_wc user.
The boot.properties
file for the Administration Server should be updated with the WebLogic admin user created in Oracle Internet Directory. Follow the steps below to update the boot.properties
file:
On SOAHOST1, go the following directory:
SOAHOST1>cd ORACLE_BASE/admin/domainName/aserver/domainName/servers/ AdminServer/security
Rename the existing boot.properties
file:
SOAHOST1> mv boot.properties boot.properties.backup
Use a text editor to create a file called boot.properties
under the security directory. Enter the following lines in the file:
username=adminUser password=adminUserPassword
Save the file.
Stop the Administration Server:
SOAHOST1> cd ORACLE_BASE/admin/domainName/aserver/domainName/bin SOAHOST1> ./stopWebLogic.sh
Start the Administrator Server:
SOAHOST1> ./startWebLogic.sh
The reassociation of both the Credential and the Policy stores is accomplished as a unit using Fusion Middleware Control or the WLST command reassociateSecurityStore
. See Section 10.1.4, "Reassociation of Credentials and Policies" for detailed steps
The domain policy store is the repository of system and application-specific policies. In a given domain, there is one store that stores all policies that all applications deployed in the domain may use. This section provides the steps to configure Oracle Internet Directory LDAP as the policy store for the Oracle Fusion Middleware WebCenter EDG topology. For more details on policy store configuration, refer to the "OPSS Authorization and the Policy Store" chapter in the Oracle Fusion Middleware Security Guide. Oracle Fusion Middleware Security Guide.
In order to ensure the proper access to an LDAP server directory (Oracle Internet Directory) used as a policy store, you must set a node in the server directory.
An Oracle Internet Directory administrator must follow these steps to create the appropriate node in an Oracle Internet Directory Server:
Create an LDIF file (assumed to be jpstestnode.ldif
in this example) specifying the following DN and CN entries:
dn: cn=jpsroot_wc cn: jpsroot_wc objectclass: top objectclass: OrclContainer
The distinguished name of the root node (illustrated by the string jpsroot_wc
above) must be distinct from any other distinguished name. One root node can be shared by multiple WebLogic domains. It is not required that this node be created at the top level, as long as read and write access to the subtree is granted to the Oracle Internet Directory administrator.
Import this data into Oracle Internet Directory server using the command ldapadd
, as illustrated in the following example (the command is shown as two lines in the example below for readability purposes, but you should enter the command on a single line):
OIDHOST1> ORACLE_HOME/bin/ldapadd -h ldap_host -p ldap_port -D cn=orcladmin -w password -c -v -f jpstestnode.ldif
Verify that the node has been successfully inserted using the command ldapsearch
, as illustrated in the following example (the command is shown as two lines in the example below for readability purposes, but you should enter the command on a single line):
OIDHOST1> ORACLE_HOME/bin/ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -b "cn=jpsroot_wc" objectclass="orclContainer"
When using Oracle internet Directory as the LDAP-Based Policy Store run the utility oidstats.sql
in the INFRADBHOSTs to generate database statistics for optimal database performance:
OIDHOSTn> ORACLE_HOME/ldap/admin/oidstats.sql
The oidstats.sql
utility must be run just once after the initial provisioning. For details about this utility, consult the Oracle Fusion Middleware User Reference for Oracle Identity Management.
An Oracle Internet Directory attribute used in a search filter must be indexed. The command ldapmodify
, whose syntax is illustrated below, can also be used to index attributes specified in an LDIF file (the command is shown as two lines in the example below for readability purposes, but you should enter the command on a single line):
OIDHOST1> ORACLE_HOME/bin/ldapmodify -h host -p port -D bindDN -w bindPassword -v -f catalogue-modify-ldif-filename
For example, the above command can be used with the following sample LDIF file to catalog the attributes createtimestamp and modifytimestamp:
dn: cn=catalogs changetype: modify add: orclindexedattribute orclindexedattribute: modifytimestamp orclindexedattribute: createtimestamp
Each of the following Oracle Internet Directory attributes must be indexed:
orclrolescope orclassignedroles orclApplicationCommonName orclAppFullName orclCSFAlias orclCSFKey orclCSFName orclCSFDBUrl orclCSFDBPort orclCSFCredentialType orclCSFExpiryTime modifytimestamp createtimestamp orcljpsassignee
Reassociating the policy store consists in migrating policy data from a file- or LDAP-based repository to an LDAP-based repository, that is, reassociation changes the repository preserving the integrity of the data stored. For each policy in the source policy store, reassociation searches the target LDAP directory and, if it finds a match, it updates the matching policy as appropriate. If none is found, it simply migrates the policy as is.
At any time, after a domain policy store has been instantiated, a file- or LDAP-based policy store can be reassociated into an LDAP-based policy store storing the same data. To support it, the domain has to be configured, as appropriate, to use an LDAP policy store.
The reassociation of both the credential and the policy stores is accomplished as a unit using Fusion Middleware Control or the WLST command reassociateSecurityStore
. See Section 10.1.4, "Reassociation of Credentials and Policies" for detailed steps.
To reassociate the policy and credential store with Oracle Internet Directory, use the WLST reassociateSecurityStore
command. Follow these steps:
From SOAHOST1, start the wlst
shell:
SOAHOST1>cd ORACLE_COMMONHOME/common/bin SOAHOST1>./wlst.sh
Connect to the WebLogic Administration Server using the wlst connect
command shown below:
Syntax:
connect('AdminUser',"AdminUserPassword",t3://hostname:port)
For example:
connect("weblogic,"welcome1","t3://SOAHOST1VHN1:7001")
Run the reassociateSecurityStore
command as shown below:
Syntax:
reassociateSecurityStore(domain="domainName",admin="cn=orcladmin", password="orclPassword",ldapurl="ldap://LDAPHOST:LDAPPORT",servertype="OID", jpsroot_wc="cn=jpsroot_wc")
For example:
wls:/SOAEDGDomain/serverConfig>reassociateSecurityStore(domain="soaedg_domain", admin="cn=orcladmin",password="welcome1",ldapurl="ldap://oid.mycompany.com:389",servertype="OID",jpsroot_wc="cn=jpsroot_wc")
The output for the command is shown below:
{servertype=OID,jpsroot_wc=cn=jpsroot_wc_idm_idmhost1,admin=cn=orcladmin, domain=IDMDomain,ldapurl=ldap://oid.mycompany.com:389,password=welcome1} Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. For more help, use help(domainRuntime) Starting Policy Store reassociation. LDAP server and ServiceConfigurator setup done. Schema is seeded into LDAP server Data is migrated to LDAP server Service in LDAP server after migration has been tested to be available Update of jps configuration is done Policy Store reassociation done. Starting credential Store reassociation LDAP server and ServiceConfigurator setup done. Schema is seeded into LDAP server Data is migrated to LDAP server Service in LDAP server after migration has been tested to be available Update of jps configuration is done Credential Store reassociation done Jps Configuration has been changed. Please restart the server.
Restart the Administration Server after the command completes successfully.
Note:
For credential and policy changes to take effect, the servers in the domain must be restarted.This section describes how to set up Oracle Access Manager as the single sign-on solution for the Oracle WebCenter EDG topology.
Oracle Access Manager (OAM) is the recommended single sign-on solution for Oracle Fusion Middleware 11g Release 1. For more information on installing and configuring an OAM installation, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management. This chapter explains the procedure for configuring the WebCenter installation with an existing OAM installation and the underlying directory service. Oracle recommends using either Oracle Internet Directory (OID) or Oracle Virtual Directory (OVD) or both of these directory services.
Note:
The WebCenter EDG topology described in this book uses a Single Sign-On configuration where both the WebCenter System and the Single Sign-On System are in the same network domain (mycompany.com) For a multi-domain configuration, please refer to the required configuration steps in "Chapter 7, Configuring Single Sign-On," of the Oracle Access Manager Access Administration Guide.The setup for Oracle Access Manager (OAM) assumes an existing OAM installation complete with Access Managers and a policy protecting the Policy Manager. For more information on installing and configuring an OAM installation, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management. This setup includes a directory service such as Oracle Internet Directory (OID) either as a stand-alone or as part of an Oracle Virtual Directory (OVD) configuration. This chapter will provide the necessary steps for configuring your WebCenter installation with either OID or OVD.
In addition, the OAM installation should have its own Web server configured with WebGate. This section also provides the steps for using the OAM Web server as a delegated authentication server.
The OAM Configuration Tool (oamcfg) starts a series of scripts and setup the required policies. It requires various parameters as inputs. Specifically, it creates the following:
A Form Authentication scheme in OAM
Policies to enable authentication in WebLogic Server
A WebGate entry in OAM to enable Oracle HTTP Server WebGates (from your Web Tier) to protect your configured application
A Host Identifier, depending on the scenario chosen (a default host identifier would be used, if not provided)
Policies to protect and unprotect application specific URLs.
This section covers the following topics:
Section 10.2.3.1, "Collecting the Information for the OAM Configuration Tool"
Section 10.2.3.3, "Verifying Successful Creation of the Policy Domain and AccessGate"
The following information should be collected or prepared prior to running the OAM Configuration tool:
Password: Create a secure password. This will be used as the password for the WebGate installation created later.
LDAP Host: host name of the Directory Server or Load Balancer address in the case of an HA/EDG configuration.
LDAP Port: port of the Directory Server.
LDAP USER DN: DN of the LDAP admin user. This will be a value such as "cn=orcladmin."
LDAP password: password of the LDAP admin user
oam_aa_host: host name of an Oracle Access Manager
oam_aa_port: port of the Oracle Access Manager
The OAM Configuration Tool resides in the ORACLE_HOME/modules/oracle.oamprovider_11.1.1/
directory (ORACLE_HOME
will depend on which machine you are running this). The tool can be run from any machine with the required installation files. In this case, we run it from SOAHOST1.
The OAM Configuration Tool should be run as follows (all on a single command line):
MW_HOME/jrockit_160_14_R27.6.4-18/bin java -jar oamcfgtool.jar mode=CREATE app_domain="WebCenter_EDG" protected_uris="$URI_LIST" public_uris="$PUBLIC_URI_LIST" app_agent_password=<Password_to_be_provisioned_for_App_Agent> ldap_host=OID.MYCOMPANY.COM ldap_port=389 ldap_userdn="cn=orcladmin" ldap_userpassword=<Password_of_LDAP_Admin_User> oam_aaa_host=OAMHOST1 oam_aaa_port=OAMPORT1
The $URI_LIST
and $PUBLIC_URI_LIST
variables in the above command depend on the topology:
WebCenter only:
$URI_LIST="/webcenter/adfAuthentication,/owc_wiki/user/login.jz,/owc_wiki/adfAuthentication,/integration/worklistapp,/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow,/workflow/WebCenterWorklistDetail/faces/adf.task-flow,/workflow/sdpmessagingsca-ui-worklist,/rss/rssservlet,/owc_discussions/login!withRedirect.jspa,/owc_discussions/login!default.jspa,/owc_discussions/login.jspa,/owc_discussions/admin,/em,/console"
$PUBLIC_URI_LIST="/webcenter,/owc_wiki,/owc_discussions,/rss,/workflow"
WebCenter and SOA:
$URI_LIST="/webcenter/adfAuthentication,/owc_wiki/user/login.jz,/owc_wiki/adfAuthentication,/integration/worklistapp,/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow,/workflow/WebCenterWorklistDetail/faces/adf.task-flow,/workflow/sdpmessagingsca-ui-worklist,/rss/rssservlet,/owc_discussions/login!withRedirect.jspa,/owc_discussions/login!default.jspa,/owc_discussions/login.jspa,/owc_discussions/admin,/em,/console, /DefaultToDoTaskFlow,/b2b,/sdpmessaging/userprefs-ui"
$PUBLIC_URI_LIST="/webcenter,/owc_wiki,/owc_discussions,/rss,/workflow"
Note:
If SOA is installed later or other additional URLs need to be protected, the OAM configuration tool should be executed again using the sameapp_domain
and including all the URLs that would be protected (not just the new ones).If your command ran successfully, you should see the following output:
Successfully connected to LDAP Processed input parameters Intialized Global Configuration
To verify the policy domain, complete these steps:
Log on to the Oracle Access Manager:
http://OAMADMINHOST:<port>/access/oblix/
Click Policy Manager.
Click the My Policy Domains link on the left panel, you will see a list of all policy domains, among which the domain you just created will be listed. It will have the suffix _PD (for example, WebCenter_EDG_PD
). In the third column (URL prefixes, you will also see the URIs you specified during the creation of this domain).
Click the link to the policy domain you just created. you will land in the General area of this domain.
Click the Resources tab, you will see the URIs you specified. You can also click other tabs to view other settings.
Verifying the AccessGate Configuration
To verify the AccessGate configuration, complete these steps:
Click the Access System Console link on the top right hand side (this acts like a toggle; after you click it, it becomes the Policy Manager link).
Click the Access System Configuration tab.
Click the AccessGate Configuration link on the left panel.
Enter 'WebCenter_EDG' as the search criterion (or any other substring you may have used as the app_domain
name in Section 10.2.3.2, "Running the OAM Configuration Tool"), and click Go.
Once the AccessGate for the domain you just created shows up (this will have the suffix _AG (for example, WebCenter_EDG_AG), click it, and the details of the AccessGate you just created appear.
The OAM Configuration Tool uses the value of the app_domain
parameter to create a host identifier for the policy domain. This host identifier must be updated with all the host name variations for the host so that the configuration works correctly. Follow the steps below to update the host identifier created by the OAM Configuration Tool:
Navigate to the Access System Console by specifying the following URL in your web browser:
http://hostname:port/access/oblix
where hostname
refers to the host where WebPass Oracle HTTP Server instance is running and port
refers to the HTTP port of the Oracle HTTP Server instance.
When prompted for a username and password, log in as an administrator. Click OK.
On the Access System main page, click the Access System Console link.
On the Access System Console page, click the Access System Configuration tab.
On the Access System Configuration page, click Host Identifiers at the bottom left.
On the List all host identifiers page, click on the host identifier created by the OAM Configuration Tool. For example, select WebCenter_EDG
.
On the Host Identifier Details page, click Modify.
On the Modifying host identifier page, add all the possible host name variations for the host. Click the plus and minus symbols to add or delete fields as necessary. The Preferred HTTP Host value used in the Access System Configuration must be added as one of the host name variations. For example: wcedg_wd
, webhost1.mycompany.com:7777
, admin.mycompany.com:7777
.
Select the check box next to Update Cache and then click Save.
A message box with the following message is displayed: "Updating the cache at this point will flush all the caches in the system. Are you sure?".
Click OK to finish saving the configuration changes.
Verify the changes on the Host Identifier Details page.
The OAM Configuration Tool populates the Preferred_HTTP_Host
and hostname attributes for the WebGate profile that is created with the value of the app_domain
parameter. Both these attributes must be updated with the proper values for the configuration to work correctly. Follow the steps below to update the WebGate profile created by the OAM CFG Tool.
Navigate to the Access System Console by specifying the following URL in your web browser:
http://hostname:port/access/oblix
where hostname
refers to the host where WebPass Oracle HTTP Server instance is running and port
refers to the HTTP port of the Oracle HTTP Server instance.
On the Access System main page, click the Access System Console link, then log in as an administrator.
On the Access System Console main page, click the Access System Configuration link to display the AccessGates Search page.
Enter the proper search criteria and click Go to display a list of AccessGates.
Select the AccessGate created by the OAM Configuration Tool. For example: WebCenter_EDG_AG).
On the AccessGate Details page, select Modify to display the Modify AccessGate page.
On the Modify AccessGate page, update:
Hostname: Update the hostname with the name of the computer where WebGate is running, for example: webhost1.mycompany.com
.
Preferred HTTP Host: Update the Preferred_HTTP_Host with one of the hostname variations specified in the previous section, for example: admin.mycompany.com:7777
.
Primary HTTP Cookie Domain: Update the Primary HTTP Cookie Domain with the Domain suffix of the host identifier, for example: mycompany.com
Click Save. A message box with the "Are you sure you want to commit these changes?" message is displayed.
Click OK to finish updating the configuration.
Verify the values displayed on the Details for AccessGate page to confirm that the updates were successful.
To assign an Access Server to the WebGate:
Log in as the Administrator on the Access System Console.
Navigate to the Details for AccessGate page, if necessary. From the Access System Console, select Access System Configuration, then AccessGate Configuration, then the link for the WebGate (WebCenter_EDG_AG).
On the Details for AccessGate page, click List Access Servers.
A page appears showing the primary or secondary Access Servers currently configured for this WebGate.
Click Add.
On the Add a New Access Server page, select an Access Server from the Select Server list, specify Primary Server, and define two connections for the WebGate.
Click the Add button to complete the association.
A page appears, showing the association of the Access Server with the WebGate. Click the link to display a summary and print this page for later use.
Repeat steps 3 through 6 to associate more Access Servers to the WebGate.
To configure the form authentication to redirect to the WebGate that was installed with the OAM installation, complete these steps:
Open the Access System Console.
In the Access System Configuration screen, select Authentication Management from the left-hand bar.
Select OraDefaultFormAuthNScheme.
Click Modify.
In the Challenge Redirect field, enter the host and port of the IDM installation; for example: http://sso.mycompany.com
.
A WebGate should already be installed in the IDM installation. Refer to Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management for details.
WebGate needs to be installed on each of the WEBHOSTn machines in order to secure the web tier:
Launch the WebGate installer (see Section 1.5.5, "What to Install" for information on where to obtain it) using the following command:
./Oracle_Access_Manager10_1_4_3_0_linux_OHS11g_WebGate –gui
The Welcome screen is displayed. Click Next.
In the Customer Information screen (Figure 10-1), enter the user name and user group that the web server is running as. Click Next to continue.
In the installation target screen (Figure 10-2), specify the directory where WebGate should be installed. Click Next to continue.
In the installation summary screen, click Next.
Download the required GCC runtime libraries for WebGate as instructed in the WebGate configuration screen (Figure 10-3), and use Browse to point to their location on the local computer. Click Next to continue.
The installer now creates the required artifacts. After that is completed, click Next to continue.
In the transport security mode screen (Figure 10-4), select "Open Mode: No Encryption" and click Next to continue.
Figure 10-4 Transport Security Mode Screen
In the WebGate configuration screen, provide the details of the Access Server that will be used. You must provide the following information:
WebGate ID, as provided when the OAM configuration tool was executed
Password for WebGate
Access Server ID, as reported by the OAM Access Server configuration
Access Server host name, as reported by the OAM Access Server configuration
Access Server port number, as reported by the OAM Access Server configuration
Note:
The Access Server ID, host name, and port are all required.You can obtain these details from your Oracle Access Manager administrator. Click Next to continue.
Figure 10-5 Access Server Configuration Screen
In the Configure Web Server screen, click Yes to automatically update the web server. Click Next to continue.
In the next Configure Web Server screen, specify the full path of the directory containing the httpd.conf
file. This file is located in the following directory:
ORACLE_BASE/admin/<OHS_Instance>/config/OHS/<OHS_ComponentName>
For example:
/u01/app/oracle/admin/ohs_instance2/config/OHS/ohs2/httpd.conf
Click Next to continue.
In the next Configure Web Server page, a message informs you that the Web server configuration has been modified for WebGate. Click Yes to confirm.
Stop and start your Web server for the configuration updates to take effect. Click Next to continue.
In the next Configure Web Server screen, the following message is displayed: "If the web server is set up in SSL mode, then the httpd.conf file needs to be configured with the SSL related parameters. To manually tune your SSL configuration, please follow the instructions that come up". Click Next to continue.
In the next Configure Web Server screen, a message with the location of the document that has information on the rest of the product setup and Web server configuration is displayed. Choose No and click Next to continue.
The final Configure Web Server screen appears with a message to manually launch a browser and open the HTML document for further information on configuring your Web server. Click Next to continue.
The Oracle COREid Readme screen appears. Review the information on the screen and click Next to continue.
A message appears (along with the details of the installation) informing you that the installation was successful.
This section assumes that you have already set up the LDAP authenticator by following the steps in Section 10.1.2.1, "Creating the LDAP Authenticator." If you have not already created the LDAP authenticator, do it before continuing with this section.
This section includes the following topics:
To be safe, first back up the relevant configuration files:
ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/config/config.xml ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/config/fmwconfig/jps-config.xml ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/config/fwmconfig/system-jazn-data.xml
Also back up the boot.properties
file for the Administration Server.
To set up the OAM ID Asserter, complete these steps:
Log into Weblogic Console, if not already logged in.
Navigate to SecurityRealms\<Default Realm Name>\Providers
.
Click New and Select "OAM Identity Asserter" from the dropdown menu.
Name the asserter (for example, "OAM ID Asserter") and click Save.
Click the newly added asserter to see the configuration screen for OAM Identity Asserter.
Set the control flag to 'REQUIRED' and click Save.
Open the Provider Specific tab to configure the following required settings:
Primary Access Server: provide OAM server endpoint information in HOST:PORT format.
AccessGate Name: name of the AccessGate (for example, WebCenter_EDG_AG
).
AccessGate Password: password for the AccessGate (optional).
Save the settings.
Reorder the OAM Identity Asserter, OID Authenticator, and Default Authenticator by ensuring that the control flag for each authenticator is set as follows:
OAM Identity Asserter: REQUIRED
OID LDAP Authenticator (or OVD LDAP Authenticator): SUFFICIENT
Default Authenticator: SUFFICIENT
Change the web.xml file for the console application to direct logins to the "/" URL. To accomplish this:
Make a backup of your WL_HOME/server/lib/consoleapp/webapp/WEB-INF/web.xml
file:
SOAHOST1>cp WL_HOME/server/lib/consoleapp/webapp/WEB-INF/web.xml WL_HOME/server/lib/consoleapp/webapp/WEB-INF/web.xml.backup
Edit the web.xml file and change the form-login-page
URL to "/".
Specifically, change:
login-config> <auth-method>CLIENT-CERT,FORM</auth-method> <form-login-config> <form-login-page>/login/LoginForm.jsp</form-login-page> <form-error-page>/login/LoginError.jsp</form-error-page> </form-login-config> </login-config>
to:
<login-config> <auth-method>CLIENT-CERT,FORM</auth-method> <form-login-config> <form-login-page>/</form-login-page> <form-error-page>/login/LoginError.jsp</form-error-page> </form-login-config> </login-config>
To enable Administration Server failover with the same SSO behavior, repeat the above steps for the installation in SOAHOST2.
Restart the Administration Server.
This section covers the following topics:
Section 10.3.2, "Configuring the WebCenter Administrator Role"
Section 10.3.3, "Configuring Discussion Server and Wiki for OAM"
There is a system property that tells WebCenter 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:
Property | Value | Comment |
---|---|---|
oracle.webcenter.spaces.osso |
true |
This flag tells WebCenter that SSO is being used, so no login form should be displayed on the default landing page. Instead, it will render a login link that the user can click to invoke the SSO authentication. |
To set this property, edit the setDomainEnv.sh
script which is located in your <adminserver_domain_home>/bin directory. Add the property to the EXTRA_JAVA_PROPERTIES
variable, as follows:
EXTRA_JAVA_PROPERTIES="-Dweblogic.security.SSL.ignoreHostnameVerification=true -Doracle.mds.bypassCustRestrict=true -Djps.update.subject.dynamic=true -Doracle.webcenter.spaces.osso=true -noverify ${EXTRA_JAVA_PROPERTIES}"
After making this change, restart the following servers:
WebCenter's Administration Server
All the domain's managed servers
WebTier OHS
After Oracle Internet Directory or Oracle Virtual Directory is configured as primary authenticator in WebCenter, the "weblogic" user should not be used as the WebCenter administrator. Create a user in Oracle Internet Directory and make that user the WebCenter administrator, either using WLST or Fusion Middleware Control:
Section 10.3.2.1, "Granting the WebCenter Spaces Administrator Role Using WLST"
Section 10.3.2.2, "Granting the WebCenter Spaces Administrator Role Using Fusion Middleware Control"
To grant the WebCenter Administrator role using WLST:
Start WLST.
Connect to the WebCenter Spaces Administration Server for the target domain with the following command:
connect('<user_name>','<password>, '<host_id:port>')
Where:
<user_name>
is the name of the user account with which to access the Administration Server (for example, weblogic
)
<password>
is the password with which to access the Administration Server
<host_id>
is the host ID of the Administration Server
<port>
is the port number of the Administration Server (for example, 7001
).
Grant the WebCenter Spaces administrator application role to the user in LDAP using the grantAppRole
command as shown below:
grantAppRole(appStripe="webcenter", appRoleName="s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator",
principalClass="weblogic.security.principal.WLSUserImpl", principalName="<wc_admin>")
where <wc_admin>
is the name of the administrator account to create.
To test the new account, log in to WebCenter Spaces using the new account name.
The Administration link should appear, and you should be able to perform all administrator operations.
This section describes how to grant the WebCenter Spaces administrator role to a user account other than the default "weblogic" account.
To grant the WebCenter Spaces Administrator role using Fusion Middleware Control:
Log into Fusion Middleware Control and select the WebLogic domain for WebCenter Spaces.
From the WebLogic Domain menu, select Security, and then Application Roles.
The Application Roles page displays.
Search for the Administration application role by selecting the Application name for WebCenter Spaces (WLS_Spaces/webcenter
), and providing the following internal identifier used by WebCenter Spaces as the Role Name:
s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator
The search should return s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator
, which is the administrator role identifier.
Click the administrator role name (s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator
) in the Role Name column.
The Edit Application Role page displays.
Click Add User.
The Add User pop-up displays.
Use the Search function to search for the user to assign the Administrator role to.
Use the arrow keys to move the user from the Available Users column to the Selected Users column, and click OK.
On the Edit Application Role page, click OK.
Restart the WLS_Spaces
managed server.
When you log in to WebCenter Spaces, the Administration link should appear and you should be able to perform all administrator operations.
This section covers the following topics:
To configure Oracle WebCenter Discussions Server for OAM single sign-on:
Log in to the Oracle WebCenter Discussions Server Admin Console at:
http://host:port/owc_discussions/admin
Where host and port are the host ID and port number of the WLS_Services managed server.
Open the System Properties page and edit, (if it already exists), or add the owc_discussions.sso.mode
property, setting its value to true
.
Edit or add the jiveURL
property to point to the base URL of the SSO server. For example:
jiveURL = example.com:8890/owc_discussions
The wiki page functionality is supported as a portlet that you can embed in a Web page (which also enables the SSO functionality). Since it does not require or support an identity store, there is no need to set up the LDAP store.
To add a wiki page to a WebCenter Group Space:
Log in to WebCenter Spaces, and navigate to a group space.
Add a page, choose Web Page as the style.
Once the page is created, click the Edit icon (pencil) on the top-right corner. In the Component Properties dialog, enter the following URL to the Source field:
http://<host>:<OHS port>/owc_wiki/page/show.jz?inline=1&scope=#{communityContext.communityName}
Note that it is the OHS port that is used, so that this will go through the WebGate which facilitates SSO.
Upon completion of specifying the component properties, the wiki page contents appear.
Save the changes.
This section covers the following topics:
Ensure that the SOA domain is using the same authenticators as the WebCenter domain and has been configured for OAM Authentication.
When associating the domain with a identity store that does not contain the user "weblogic", you must assign some other valid user into the application role BPMWorkflowAdmin. To assign the role to a valid user, the following may be done:
Create a user in LDAP Store, in this case named WCAdmin, who will be assigned the role.
Assign the role. This can be done using wlst from the SOA Oracle home:
For example:
cd $ORACLE_HOME/common/bin/ wlst.sh connect('weblogic','weblogic', 'SOAADMINHOST:7001') revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="oracle.security.jps.service.policystore.ApplicationRole", principalName="SOAAdmin") grantAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSUserImpl", principalName="WCAdmin")
After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded once the enterprise deployment setup is complete. At this point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in this guide. For information on how to recover components, see "Recovery of Components" and "Recovery After Loss of Component" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" in the guide. Also refer to the Oracle Database Backup and Recovery User's Guide for information on database backup.
To back up the installation a this point, complete these steps:
Back up the web tier:
Shut down the instance using opmnctl
.
ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall
Back up the Middleware Home on the web tier using the following command (as root):
tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
Back up the Instance Home on the web tier using the following command (as root):
tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
Start the instance using opmnctl
:
ORACLE_BASE/admin/<instance_name>/bin/opmnctl startall
Back up the AdminServer domain directory. Perform a backup to save your domain configuration. The configuration files all exist under the ORACLE_BASE/ admin/<domain_name>
directory.
SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>