| Oracle® Access Manager Integration Guide 10g (10.1.4.2) Part Number E10356-01 |
|
|
View PDF |
| Oracle® Access Manager Integration Guide 10g (10.1.4.2) Part Number E10356-01 |
|
|
View PDF |
The Oracle Access Manager Connector for WebSphere enables you to integrate applications running on IBM's WebSphere Application Server with the Access System's authentication and authorization services. The connector also makes users and groups managed by Oracle Access Manager available for authentication and authorization within WebSphere.
This chapter describes how prepare your environment, then install, set up, and test the Oracle Access Manager Connector for WebSphere, and configure your WebSphere Application Server for Oracle Access Manager.
This chapter covers the following topics:
The Oracle Access Manager Connector for WebSphere enables WebSphere Application Server administrators to integrate applications running on WebSphere with Access System authentication and authorization services.
Using the Connector for WebSphere, users who try to access Access System-protected WebSphere resources are challenged and authenticated by the Access System. The connector also makes Identity System-managed users and groups available for authentication and authorization.
Advantages of using the Connector for WebSphere include:
Providing information about Identity System-managed users and groups to the WebSphere Security Server for authentication and authorization.
Using the Access System to authenticate users who access WebSphere resources such as JSPs, EJBs, and Servlets.
You can use Access System authentication schemes to provide single sign-on for Web and non-Web enabled applications.
Authorizing users who access WebSphere resources.
Oracle Access Manager supports WebSphere's security role-based authorization. The WebSphere's role-based authorization grants access to a protected resource based on a role (such as Manager) for a user or group. Oracle Access Manager integrates WebSphere Server security roles with the Access System's policy-based authorization.
Protecting WebSphere Server resources such as administration tools, events, servlets, passwords, JDBC connection pools, JMS destinations, and JNDI contexts.
You can use WebSphere's role-based access policies to control access to WebSphere resources.
Enabling single sign-on between an Access System-protected resource and a WebSphere Server resource that is protected with WebSphere Security constraints.
The following is an overview of the integration.
Task overview: Integrating with the WebSphere Application Server
Prepare your environment, as described in "Preparing Your Environment".
Install the Connector, as described in "Installing the Connector for WebSphere".
Set up and test the Connector, as described in "Completing Connector Setup".
Configure your WebSphere Application Server, as described in "Configuring WebSphere Application Server v5".
Integrate with the WebSphere Portal Server, if this is part of your environment, as described in "Integrating with WebSphere Portal".
Oracle Access Manager supports the WebSphere Application Server Network Deployment architecture. The Network Deployment architecture comprises of a set of Application Server nodes managed together as a cell. Use the following steps to integrate Oracle Access Manager with the Network Deployment architecture:
Complete the preceding steps, numbered 1 to 5, to separately integrate each standalone node with Oracle Access Manager. You must complete the integration before configuring the Network Deployment architecture.
Set up the Network Deployment architecture. For more information, refer to the IBM WebSphere InfoCenter documentation at:
As you complete activities in this chapter, you will see the following path name formats:
Identity_install_dir: The directory where you installed the Identity Server. In your installation, for example, this may be C:\OracleAccessManager. During installation the \identity subdirectory is added to the specified destination making the full path to the directory where you installed the Identity Server Identity_install_dir\identity.
WebGate_install_dir: The directory where you installed the Access System WebGate. In your installation, for example, this may be C:\OracleAccessManager\Webcomponent. During installation the \access subdirectory is added to the specified destination making the full path to the directory where you installed the WebGate WebGate_install_dir\access.
CWS_install_dir: The directory where the Connector for WebSphere was installed. In your installation, for example, this may be C:\OracleAccessManager\NetPointWASRegistry.
WAS_install_dir: The directory where the WebSphere Application Server is installed. In your installation, for example, this may be C:\IBM\WebSphere\AppServer.
WPS_install_dir: The directory where the WebSphere Portal Server is installed. In your installation, for example, this may be C:\IBM\WebSphere\PortalServer. This directory is used for the Portal logs such as, WPS_install_dir/log/appserver-out.log.
When you see one of the notations shown in the previous paragraphs, substitute the appropriate path name for your environment as you complete the step.
The rest of this section discusses the following topics:
For complete support information, see "Supported Versions and Platforms". The following WebSphere components are used in the integration between WebSphere and Oracle Access Manager:
WebSphere Application Server (WAS): The WebSphere Application Server (WAS) enables secure, high volume transactions and Web services.
WAS 5.0/5.1 is J2EE 1.3 compliant
WAS 6 and 6.1 are J2EE 1.4 compliant
Note:
Both implement authorization using the EJB1.1 specification for security roles. A security role is a set of permissions for access to Web resources and specific EJB methods.WebSphere Portal Server (WPS): The WebSphere Portal Server provides single sign-on for portlets based on the Java Authentication and Authorization Services (JAAS). The single sign-on implementation enables portlet developers to extract:
A user's username and password, and distinguished name (DN)
The DNs of any groups that the user belong to
The WebSphere Application Server CORBA Credential
The LTPA token
Any combination of these objects can be used to provide single sign-on to the portlet's back end. For example, the username and password may be used to create a Basic Authentication HTTP header. Or the LTPA Token may be used to provide single sign-on to another WebSphere Application Server in the same security domain.
Web Trust Association Interceptor (TAI): The TAI is used for third-party proxy authentications. The WebSphere Application Server uses the TAI to enforce the trust policy between WebSphere and third-party security providers for single sign-on. The TAI enables the Access System to authenticate users who try to access resources on the WebSphere Application Server.
Application Assembly Tool (AAT): The AAT is used to build security-aware applications. You use the AAT to define WebSphere roles and bind them to Identity System users and groups.
The Connector for WebSphere uses the Trust Association Interceptor (TAI), the Identity System, the Access System, and the following components:
NetPointWASRegistry: This is the Connector for WebSphere. The NetPointWASRegistry is a user data store implementation of the WebSphere CustomRegistry in Oracle Access Manager. The NetPointWASRegistry serves as a plug-in to the WebSphere Application Server (WAS).
The WebSphere CustomRegistry is also known as a custom user registry (CUR). The CustomRegistry defines the methods that the WAS uses to perform security operations for applications configured to use them. For example, the WebSphere CustomRegistry may be used to identify attributes such as username and password, and to combine user information from diverse data sources.
The NetPointWASRegistry consists of the Access Manager SDK and Identity XML. The NetPointWASRegistry establishes a native connection between the WAS and Oracle Access Manager, enabling WebSphere administrators to use policy-based security features to control user access to business applications.
IdentityXML: The Connector for WebSphere uses IdentityXML calls to get user and group information from the Identity Server. Typically, you use IdentityXML to integrate the Identity System with external software systems and to perform Identity System functions programmatically rather than using the Identity System GUI.
Access Manager SDK: The Access Manager Software Developer's Kit (SDK) enables you to create an interface that can be built into WebSphere and to create an AccessGate that communicates with the Access Server for authentication purposes. The SDK is installed automatically when you install the Connector for WebSphere. The SDK is used by the TAI.
Custom Member Repository (CMR): The CMR is an extension of the Oracle Access Manager component called NetPointWASRegistry (a custom user registry). It resides on the WebSphere Portal Server. The WebSphere Portal Server uses WebSphere Application Server security for authentication when logging in to the Portal. The WebSphere Portal Server enables users to customize and personalize their experience and uses a component called Member Services to manage information about users, user accounts, user profile attributes, and group memberships.
The CMR is an instance of a Member Services component. The CMR connects the WebSphere Portal Server to the Identity System users and groups. The CMR implements the IBM WebSphere MemberRepository interface, and is used to assign and determine access control to the portlets. The CMR stores user.baseattributes and group.baseattributes. It supports only read operations, not create or modify or delete operations.
The WebSphere Portal Server will use the CMR to make IdentityXML queries like getAttributes for a user for personalization, getGroupMemberships, search users by attribute, and similar functions.
Note:
The Connector for WebSphere does not support getGroupMemberships. As a result, in the case of Nested Groups, if you check for inner group membership the parent group details will not be displayed.For more information, see the "Supported Versions and Platforms".
The integration between WebSphere and Oracle Access Manager can vary depending on if you use only the NetPointWASRegistry or if you also use the Access System's single sign-on. For details, see:
For additional information, see "Mapping Users and Groups to Security Roles in WAS". See also "Integration Scenario with the Oracle Access ManagerCMR".
The NetPointWASRegistry obtains Identity System-managed user and group information and performs authentication based on that information.
Figure 11-1 illustrates an implementation of the Connector for WebSphere using the NetPointWASRegistry.
In this scenario, use of a WebGate is optional. The WebGate is needed only for single sign-on or to protect the WebPass.
Note:
In this scenario, The WAS and both the Web servers must belong to the same domain.Process overview: Login using WAS with the NetPointWASRegistry
A user tries to access a WebSphere resource through a browser.
The WAS forwards the user's request to the Connector for WebSphere.
The Connector for WebSphere checks with the Access Server and authenticates the user.
If single sign-on is enabled in the WAS, an LTPA token is generated.
The Connector for WebSphere queries the Identity Server via WebPass for a list of groups to which the user belongs.
The Identity Server checks the directory and returns the information to the Connector for WebSphere.
The Connector for WebSphere returns this information to the WAS.
The WAS checks the deployment descriptor for a user-security or group-security role mapping.
If the user or group belongs to a security role that is allowed to access the resource, the WAS enables the user to access the resource.
The Access System's single sign-on feature enables authenticated users to access protected resources without having to re-authenticate. To use the Access System's single sign-on, you must enable the TAI and install an AccessGate plug-in on the Web server servicing WAS.
Figure 11-2 illustrates WAS using Access System single sign-on.
Note:
In this scenario, a WebGate is required for single sign-on.Process overview: Login using the WAS with Access System single sign-on
The user attempts to access an WebSphere resource that is protected by the Access System.
WebGate (or AccessGate) intercepts the request and prompts for a username and password, using the Basic challenge method.
WebGate passes the user's credentials to the Access Server.
The Access Server checks the user data store (the directory) and authenticates the user. WebGate sets an ObSSOCookie in the request.
The Web server forwards the user request to the WAS.
The Oracle Access Manager TAI gets the request and confirms that the user has been authenticated.
WAS recognizes that the Access System has authenticated the user and creates an LTPA token.
The remaining steps in this process are the same as steps 5-7 in Scenario 1. The WAS and both Web servers must belong to the same domain.
The Connector for WebSphere queries the Identity Server via WebPass for a list of groups to which the user belongs.
The Identity Server checks the directory and returns the information to the Connector for WebSphere.
The Connector for WebSphere returns this information to the WAS.
If you are using the Oracle Access Manager CMR, the Portal Server is invoked, as described in "Integration Scenario with the Oracle Access ManagerCMR".
If you are not using the CMR, the WAS checks the deployment descriptor for a user-security or group-security role mapping. If the user or group belongs to a security role that is allowed to access the resource, the WAS allows the user to access the resource.
WebSphere security is consistent with J2EE role-based security specifications. Roles are specified in the deployment descriptors for an application. When the application is installed, these roles are bound to Oracle Access Manager users or groups. You can change the binding information for roles in an application through the WebSphere Administrative Console.
Oracle Access Manager manages users and groups. WebSphere manages roles with the help of the AAT or via the Administration Console. The following illustration shows Oracle Access Manager mappings of Identity System users to Identity System groups and Identity System users and groups to WebSphere roles. It also shows WebSphere mappings of methods to roles.
In the WAS 5 Administrative Console, the role of "Admin" is special. Any user added to the role "Admin" in the Identity System must be in a group called "Admin" or "Administrator". Otherwise, this user may not be able to login to the Administrative Console. Other roles, like "monitor" have no restrictions. Therefore, any Oracle Access Manager user added to these roles in the WAS 5 Administrative Console, can log in to the WAS 5 Administrative Console.
During login, the user is authenticated as depicted in "Integration Architecture". Without the CMR, the WebSphere Portal Server must communicate directly with the LDAP directory server to obtain user, group, and personalization information. With the CMR, communication between the WebSphere Portal Server and the directory server can be eliminated. The CMR performs read operations through the NetPointWASRegistry with the directory server.
Figure 11-3 shows the interaction between the WebSphere Portal Server, CMR, and LDAP directory server during the login authorization process. This follows processes described in "Integration Architecture".
Process overview: Authorization with the CMR
After authentication, a user requests access to a portlet through the WebSphere Portal Server.
The Portal Server forwards the request to the Oracle Access Manager CMR.
The CMR forwards the request to the NetPointWASRegistry.
The NetPointWASRegistry sends an IdentityXML call to the Identity Server or uses the Access Manager SDK to contact the Access Server through WebPass or WebGate, depending upon the required method.
For instance, the Access Manager SDK uses the checkPassword method while IdentityXML uses all other methods:
findByAttribute to search users by attribute
get
getGroupMemberIdentifiers
getMemberAttributes
getMemberships
IsAttributeSupported
searchMembers
The Identity Server (or Access Server) communicates with the LDAP directory server.
The directory server returns information.
The Connector for WebSphere includes the Oracle Access Manager Custom Member Repository (CMR) for the WebSphere Portal Server. The Connector for WebSphere supports the WebSphere Application Server v5.0 and 5.1 with the CMR.
Any references to versions and platforms in this chapter are for demonstration purposes.
You can find support and certification information at the following URL:
http://www.oracle.com/technology/documentation/
You must register with OTN to view this information.
Also, you can see the supported versions and platforms for this integration on Metalink, as follows.
To view information on Metalink
In your browser, enter the following URL:
Log in to MetaLink.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Identity Management and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, Oracle Access Manager Certification to display the certification matrix.
Before you can install and configure the Connector for WebSphere, you must complete the following tasks.
Task overview: Preparing to install the Connector for WebSphere
Install IBM and Oracle Access Manager components, as described in "Preparing Your Environment".
Configure the Identity Server after installation, as described in "Configuring the Identity System for WAS Integration".
Complete Access System configuration, as described in "Configuring the Access System for WAS Integration".
Set up resource protection, as described in "Configuring Resource Protection in the Access System".
Define a policy domain for the Websphere Administration Console, as described in "Defining a Policy Domain for the WebSphere v6.0 Administration Console".
Preparing your environment includes installing the appropriate IBM applications and Oracle Access Manager.
To prepare your environment for integration
Ensure that your environment meets the requirements under "Supported Versions and Platforms".
Install and configure the following IBM applications and components using the IBM documentation for these products:
IBM WebSphere Application Server
Application Assembly Tool (AAT)
WebSphere Portal Server.
The Oracle Access Manager CMR requires the WebSphere Portal Server. References to specific versions are for demonstration purposes. See "Supported Versions and Platforms" for details.
WebSphere Portal Server v5: See "Supported Versions and Platforms" then follow instructions from IBM as you complete one of the following steps to ensure you have an up-to-date version that includes Fix Pack PQ93461:
Note:
Fix Pack PQ93461 is already included incorporated in Portal 5.1.Install a new WebSphere Portal 5.0.2 instance using the installation program provided for v5.0.2.
Upgrade an existing installation of WebSphere Portal 5.0 to v5 .0.2.
Install a new WebSphere 5.1 Portal instance using the installation program provided for v5.1.
Upgrade an existing installation of WebSphere Portal 5.0 or 5.0.2 to 5.1
Install and setup Oracle Access Manager components, as described in the Oracle Access Manager Installation Guide:
Identity Server
WebPass
Policy Manager
Access Server
WebGate
AccessGate
Configure the WAS integration, as follows:
Identity System: See "Configuring the Identity System for WAS Integration" for details.
Access System: See "Configuring the Access System for WAS Integration" for details.
Configure Access System resource protection for WAS, as described in "Configuring Resource Protection in the Access System".
The Identity Server and WebPass are the two main components of the Identity System. WebPass is an Access System plug-in for Web servers. When a user requests access to a Web server resource, the WebPass redirects the request to a Identity Server, which then checks the user's identity through the directory server.
After you install the Identity Server and a WebPass, you must set up the Identity System, as explained in the Oracle Access Manager Installation Guide. After setup, you configure the Identity System for integration as follows.
Task overview: Configuring the Identity System for WAS integration
Prepare for WebPass failover, if desired, as described in "Configuring WebPass Failover".
Setup the Identity Server for WAS, as described in "Configuring the Identity Server".
Oracle Access Manager uses failover to maximize performance and provide uninterrupted service to end users. Failover redirects requests in the event that a server fails. You must install a WebPass plug-in on each Web server. You may want to install multiple instances of WebPass. Later you may configure these for failover.
For more information, see "Configuring Multiple WebPass Instances for the Connector".
The Identity Server is the Oracle Access Manager component that provides user and group information to the WAS. You must configure the Identity Server to be compatible with search methods that may be used with the WAS.
You will configure the account for the NetPointWASRegistry Admin user. The administrator's login will be used to make IdentityXML calls to the Identity Server. The NetPointWASRegistry Admin user does not need to be the Master Administrator. For example, the NetPointWASRegistry Admin user may be the Master Identity Administrator. However, if you prefer to limit the rights, the administrator you assign must possess at least the following rights:
View access on the class attribute of the user class.
View access on the class attribute of the Group class.
The appropriate searchbase for the user and group class.
GRANT+READ right on the class attribute of the user class.
GRANT+READ right on the class attribute of the Group class.
View access on those attributes listed in the call. For example: login ID, group member, group dynamic filter, and so on.
To configure the Identity Server after installation
Open the oblixappparams.xml file and set the searchstringMinimumLength to zero:
Identity_install_dir \identity\oblix\apps\common\bin\oblixappparams.xml
<NameValPair ParamName="searchstringMinimumLength" Value="0"/>
where Identity_install_dir is the directory where you installed the Identity Server.
Open the groupservcenterparams.xml file and set the groupMemberSearchStringMinimumLength to zero:
Identity_install_dir \identity\oblix\apps\groupservcenter\bin\groupservcenterparams.xml
<NameValPair ParamName="groupMemberSearchStringMinimumLength" Value="0"/>
Restart the Identity Server.
The next step must be completed after Identity System setup.
From the Identity System Console, click the User Manager tab, then click the Configuration sub-tab.
Click the Delegated Administration link and provide an administrator with the required View and Delegated Administration rights, as follows.
Caution:
Do not check the Delegate Right box beside Grant Read Right.
Restart WAS and the WAS Admin Console to have the change take effect.
For more information about configuring administrators, see the Oracle Access Manager Identity and Common Administration Guide.
The Access System has three main components: the Policy Manager, the Access Server, and the WebGate. Installation and configuration considerations for Access System components in a WAS integration are discussed here.
Policy Manager: The first component you install is the Policy Manager. You use the Policy Manager to create and manage policy domains to protect resources, and to test policy enforcement. The Access System Console is a part of the Policy Manager. The Access System Console is used for system configuration and system management tasks such as configuring administrators, managing logs, and configuring instances of AccessGates and Access Servers.
Access Server: You also must install at least one Access Server. However, it is recommended that you install at least two Access Servers on two different machines to ensure uninterrupted service to your users.
Each Access Server can be configured to communicate with one or more WebGate instances, and to communicate with a directory server. Access Servers record their activity in Greenwich Mean Time (GMT) because you could have servers operating in several time zones.
WebGate: The WebGate component is optional. You will need it if you want to support single sign-on and if you want to protect the WebPass.
AccessGate: An AccessGate is a an Access System component that processes Web and non-Web resource requests from users or applications. The Connector for WebSphere uses an AccessGate to communicate with the Access Server.
Note:
For more information, see "Configuring the AccessGate for WAS Integration" and the Oracle Access Manager Access System Administration Guide.Before installing the Connector for WebSphere, you must install and configure an AccessGate. WebSphere intercepts user requests and passes them on to the Connector for WebSphere. The Connector uses the AccessGate to make calls to the Access Server for authentication and authorization of the requests.
To configure the AccessGate for the NetPointWASRegistry
Navigate to the AccessGate Configuration page:
From the Access System Console, click Access System Configuration, then click AccessGate Configuration.
Click the Add button to display the Add a new AccessGate page.
Complete the following information:
AccessGate Name: Unique, descriptive name for this AccessGate. Use an alphanumeric string, and do not include spaces in the name.
Hostname: Name of the machine where the AccessGate will be installed.
Port: You do not need to specify a port. An AccessGate, unlike a WebGate does not require a port number. See the Oracle Access Manager Access System Administration Guide for details.
AccessGate Password and Re-type AccessGate Password: Unique password to verify and identify the component regardless of the transport security mode. This should differ for each AccessGate instance.
Access Management Service: This service only needs to be enabled if the Access Server that you are associating with this AccessGate has Access Management Service set to On.
Transport Security: Level of transport security to and from the Access Server. The default value is Open. The transport security mode of the AccessGate must match the transport security mode of the Access Server.
See the Oracle Access Manager Access System Administration Guide for details on transport security.
Click Save.
The Details for the AccessGate page appears.
Click the List Access Servers (or List Clusters) button to associate this AccessGate with the appropriate Access Server.
Click the Add button to add a new Access Server to associate with this AccessGate.
Select an Access Server from the list, and define the configuration for this Access Server.
Review the page that is returned.
For more information about AccessGates, see the Oracle Access Manager Access System Administration Guide.
The following procedures must be completed to configure the Access System to protect resources for WebSphere.
Task overview: Configuring resource protection in the Access System
Identify a resource type, as described in "Defining a Resource Type for WebSphere".
Create an authentication scheme, as described in "Defining an Authentication Scheme for WebSphere".
Create a policy domain in the Access System, as described in "Defining a Policy Domain for WebSphere".
For WebSphere Application Server v6.0, create a policy domain in the Access System, as described in "Defining a Policy Domain for the WebSphere v6.0 Administration Console".
Define a resource type for WebSphere, as described in the following procedure. See the Oracle Access Manager Access System Administration Guide for details on defining resource types.
In the following procedure you must provide the resource type values exactly as specified. If you need to specify a different resource name, you must change the resource name in the following locations:
CWS_install_dir \oblix\config\NetPointWASRegistry.properties
where CWS_install_dir is the directory where the Connector for WebSphere was installed.
WAS_install_dir \properties\webgate.properties
where WAS_install_dir is the directory where the WebSphere Application Server is installed.
By default, these configuration files assume you entered the values specified in the following procedure.
To define a resource type for WebSphere
From the Access System Console, click Access System Configuration, then click Common Information Configuration.
Click Resource Type Definitions.
The Details for Resource Type page appears.
Define and save the resource type as follows:
Resource Name: Authen
Display Name: WebSphere Authentication Scheme
Resource Matching: Case Insensitive
Resource Operation: LOGIN.
Restart the Access Server to make this new resource available.
You need to define an authentication scheme for WebSphere. The authentication scheme provides a method to be used when determining whether a user is allowed to access an Access System-protected WebSphere resource.
Note:
See the Oracle Access Manager Access System Administration Guide for more information on authentication schemes.To define an authentication scheme for WebSphere
From the Access System Console, click Access System Configuration, then click Authentication Management.
Define and save the authentication scheme as follows.
Name: WebSphere Basic Over LDAP
Description: Used to protect WebSphere-related URLs
Level: Enter a number for security level that is lower than or equal to the level specified in the authentication scheme protecting the WebSphere and Portal Server URLs. For details, see "Configuring the TAI for WebSphere v5" or "Configuring the TAI for WebSphere 6 and 6.1".
Challenge Method: Basic
Challenge Parameter: Set the challenge parameter for the user credentials that you want to map.
SSL required: No
Challenge Redirect: Enter information in this field if you are going to redirect the end user's request to another server for the authentication process. The most common use of this field is to redirect from a non-SSL server to an SSL server. Redirection is transparent to the end user.
Plug-ins: Select Access System plug-ins to create a customized challenge scheme. For example, the Oracle Access and Identity challenge scheme requires the validate_password and credential_mapping plug-ins.
Now you need to create a policy domain for the WebSphere Application Server, as described next.
Note:
See the Oracle Access Manager Access System Administration Guide for details on policy domains.You need to use the Access System to create a policy domain for WebSphere. This policy domain identifies the authentication scheme that WebSphere will use to protect the resource type that you configured in "Defining a Resource Type for WebSphere". You also define an action in the Access System. This action creates a user attribute for the WebSphere Application Server. When a user is authenticated to WebSphere, the user ID defined on the action is sent to the WebSphere Application Server.
To create a policy domain for WebSphere
From the Policy Manager, click Create Policy Domains.
Click the General tab and enter and save the information for your organization. For example:
Name: WebSphere
Description: Policy Domain Used for WebSphere
Enabled: Yes
Update Cache
Click the Resources tab, then enter and save the following information for your organization. For example:
Resource Type: WebSphere Authentication Scheme
This is the resource you defined earlier. If you changed the name of the WebSphere resource type, ensure that you specify it here.
URL Prefix: /Authen/Basic
Description: NetPointWASRegistry uses this resource for authenticating users in the Access System. Do not delete this resource.
Click the Default Rules tab, Authentication Rules, Add to create and save a default authentication rule using the WebSphere Basic Authentication Scheme that you defined earlier.
Name: WebSphere
Description: Default authentication rule using the WebSphere Basic Authentication Scheme.
Authentication Scheme: Basic Over LDAP type
You must create a Basic Over LDAP authentication scheme. The Access Manager SDK uses only this type of authentication scheme. You can create a new authentication scheme with a different name for WebSphere, but the authentication scheme type must be Basic Over LDAP.
Click the Authorization Rules tab, then create and save an authorization rule to allow access to WebSphere resources. For example:
Click General, then enter and save:
Name: Allow Everyone.
Description: Allow access to WebSphere resources.
Enabled: Yes
Allow takes Precedence: Yes
By default, nobody is allowed. Changing the default to Allow Everyone enables the Access Server to check a user's identification for authentication.
Click Actions (Authorization Success), then enter and save:
Return Type: WAS_REGISTRY
Name: uid
This is a hard-coded value. Use this exact string.
Return Attribute: login attribute.
This attribute must be the same as the attribute configured for the login semantic type in the Identity Server or a unique attribute in the user's profile, such as uid.
Click Allow Access, then enter and save:
Role: Anyone
Click OK to create the new policy domain.
You can now install the Connector for WebSphere.
For Websphere 6.0, you must use the Access System to create a policy domain for the WebSphere administration Console. This domain protects the console URLs in the ibm/console and /admin folders, and it is required when TAI is enabled for the WebSphere AppServer. The domain helps set the TAI cookie required by the TAI component, and it also redirects the access URL to the application server Administration Console (port 9060). Under these conditions, you must also set an Authorization Success URL
To create a policy domain for the WebSphere Administration Console
Navigate to Policy Manager, Create Policy Domains, General.
Enter and save the following information for your organization.
For example:
Name: Protect WebSphere Admin Console
Description: Policy Domain Used for the WebSphere Administration Console URL
Click the Resources tab, then enter and save the following information for your organization
For example:
Resource Type: http
Host Identifier: The host identifier defined for the machine hosting the Web server.
URL Prefix: /admin and ibm/console
Description: Used by NetPointWASRegistry TAI component.
Click the Authorization Rules tab, then create and save an authorization rule to allow access to WebSphere Admin Console resources
For example:
Click General, then enter and save:
Name: Allow Administrator.
Description: Allow access to WebSphere Admin Console resources.
Enabled: Yes
Allow takes Precedence: Yes
By default, nobody is allowed. Changing the default to only Administrator User enables the Access Server to check a user's identification for authentication.
Click Actions (Authorization Success), then enter and save the following:
Redirect to: http://hostname:9060/ibm/console
If the Client Cert Authentication Scheme is to be used, set the associated variables as:
Redirect to: https://hostname:9043/ibm/console
Where hostname is the fully qualified domain name of the machine hosting the WebSphere AppServer.
Click Allow Access
Select the User who has Administrative rights, then click Save.
To create a default authentication rule using the desired authentication scheme, (Basic Over LDAP, Form-based, Client Cert), navigate to Default Rules, then click Authentication Rules, then click Add. Enter and save the following values:
Name: WebSphere Default Scheme
Description: Default authentication rule for Admin Console.
Authentication Scheme:
Create this scheme as a Basic Over LDAP, Form-based, or Client Cert authentication scheme.
To create an authorization expression using the "Allow Administrator" authorization rule created previously, navigate to Default Rules, Authorization Expression, Add, then click Select Authorization Rule - "Allow Administrator". Next, click Add and Save
Install the Connector for WebSphere.
After you install and set up the connector and have also enabled TAI, enable the policy by completing the following steps:
Navigate to General, Modify.
Set Enable to YES, then click Save.
At this point, you can access the WebSphere Administration Console through either of the following URLs:
http://WebServerFQDN:port/admin
http://WebServerFQDN:port/ibm/console
Where WebServerFQDN is the fully qualified domain name of the machine hosting Web server and port is the port number used by the Web server.
After completing the prerequisites described in the previous sections, you are ready to install the Connector for WebSphere, as follows.
Caution:
If you plan to include the WebSphere Portal Server in your integration, you must install and configure the portal before you install the Connector for WebSphere. See "Preparing Your Environment".
Tip:
For information on upgrading this integration, see the Oracle Access Manager Upgrade Guide.Task overview: Installing the Connector
Run the installer, as described in "Launching the Installation".
Create an installation directory, as described in "Defining the Installation Directory".
Configure the Connector, as described in "Specifying Connector Details".
Configure the WebGate, as described in "Completing Details for the WebGate"
Configure the AccessGate, as described in "Specifying AccessGate Details".
Install a certificate, as described in "Installing a Certificate"
Configure WebPass, as described in "Configuring Multiple WebPass Instances for the Connector".
The initial installation and setup procedure differs depending on the platform on which you are installing Oracle Access Manager.
Insert the installation CD.
The DemoShield launches.
Launch the program according to your platform:
Windows: Navigate to Install Oracle Access Manager, Access System, Connector for WebSphere.
Unix: Complete these steps:
Navigate to /Software/Solaris/AccessSystem/Connector for WebSphere.
Execute /COREidx.x_EN_sparc-s2_Connector_for_WebSphere.
The install wizard launches.
In this sequence, you will accept the terms of the license agreement and identify the installation directory for the Connector for WebSphere.
You need to specify the installation directory for the Connector for WebSphere on the machine where you installed WAS.
To define the installation directory
Click Next to dismiss the Welcome Screen.
Read and accept the terms of the license agreement, then click Next to continue.
Respond to the next question based upon your platform. For example:
Windows: Click Next if you are logged in with administrator rights (otherwise click Cancel, log in as a user with administrator privileges, then restart the installation).
Unix: Specify the username and group, then click Next.
Typically, the defaults are "nobody".
You are asked to specify the installation directory for the Identity Server. When you do this and click Next, the installation will begin and you will not be able to return to restate the name.
Accept the default directory by clicking Next (or change the destination, then click Next).
For example:
\Netpoint
You are informed that the connector is being installed, which may take several seconds.
The Configuration for Oracle Access Manager Connector for WebSphere screen appears.
You need to configure the WebPass for the Connector for WebSphere. For failover purposes, you can configure multiple WebPass instances during installation or through the NetPointWASRegistry.properties file.
To configure multiple WebPass instances during installation, when you enter the WebPass hostname and port number be sure to use a comma as a separator. The hostname must be fully qualified with the domain name. For example:
Hostname: foo.domain.com, bar.domain.com
Port Number: 80, 81
Where the valid WebPass host:port combinations are:
foo.domain.com:80
bar.domain.com:81
For details about configuring multiple WebPass instances through the properties file, see "NetPointWASRegistry.properties".
To specify Connector for WebSphere details
Enter the information requested:
Hostname of WebPass: The fully qualified name of the machine on which WebPass is installed.
Port Number of WebPass: The port number for WebPass.
Is the Identity System (WebPass) protected by WebGate: Specify whether the Identity System (WebPass) is protected by a WebGate.
Click Next.
If the Identity System WebPass is protected by a WebGate, the WebGate configuration screen appears.
The following procedure describes how to provide WebGate configuration details.
Note:
If you have chosen to use WebGate to protect WebPass, the assumption is that you are protecting the Identity System applications with policy domains. It is also assumed that single sign-on between these components has been configured correctly.To complete WebGate configuration details
Enter the cookie domain for the WebGate (for example, .domain.com).
The ObSSOCookie is then recognized by all servers within this domain.
Enter the cookie path ( /).
Click Next.
Specify whether WebPass requires an HTTPS connection.
This is the SSL for secure connection when WebPass runs on HTTPS.
Specify the user attribute.
This attribute must be the same as the attribute configured for the Login semantic type in the Identity Server or a unique attribute in the user's profile such as uid.
Specify the user search attribute.
The user attribute and the user search attribute cannot be the same.
This attribute must be the same as the attribute configured for the DN Prefix semantic type for the person object class in the Identity Server. The person object class type must a structural object class. The administrator of your directory server sets this search attribute.
Specify the group search attribute.
This attribute must be the same as the attribute configured for the DN Prefix semantic type for the group object class in the Identity Server. The group object class a structural object class. The administrator of your directory server sets the group search attribute.
You can select Yes to specify that you want the Connector for WebSphere's jar files to be copied from the Connector for WebSphere installation directory to the following directory:
WAS_install_dir /classes
Where WAS_install_dir is the directory where you installed WebSphere.
For WebSphere 6.x and later versions, the classes folder is not present by default. Create the classes folder under the WAS_install_dir and click OK to copy the JAR files.
If you select No, copy the jobaccess.jar and NetPointWASRegistry.jar files manually to the WAS_install_dir/classes after installation. Or, add the location of these jar files to the WebSphere runtime classpath.
Be sure that .../classes folder path is mentioned in the WAS CLASSPATH in setupCMDline.sh script.
This script is located in the folder WAS_INSTALL_DIR/bin.
This enables the NetPointWASRegistry.jar files to be searched when WebSphere starts up.
Click Next.
The WebSphere Classes Directory screen appears.
As described in the following procedure, you specify the transport security mode for the AccessGate and other AccessGate details. See the Oracle Access Manager Access System Administration Guide for details on AccessGates.
Select the same transport security mode that is specified for the Access Server
The pages that you see next vary depending on the transport security mode that you selected. See the Oracle Access Manager Installation Guide for details.
Click Next.
Enter the following information for the AccessGate:
AccessGate ID: Enter the name you specified earlier when adding an AccessGate in the Access System Console.
Access Server ID: Enter the name of the Access Server you associated with this AccessGate.
Password for AccessGate: Enter the AccessGate password you specified earlier when adding an AccessGate in the Access System Console, if applicable.
You can specify any Access Server that is associated with this AccessGate.
Hostname where Access Server is installed: Enter the fully qualified hostname for the Access Server you associated with this AccessGate; for example, stontium.oblix.com.
Port Number Access Server Listens To: Enter the port of the Access Server you associated with this AccessGate.
Global NetPoint Access Protocol Pass Phrase: Enter a pass phrase for all Oracle Access Manager components such as Access Server and WebGate.
This field appears only if you specify Simple Mode or Cert Mode.
Global NetPoint Access Protocol Pass Phrase Confirmation: Reenter the pass phrase to confirm it.
Click Next.
A new AccessGate Configuration screen appears only if you specify Simple Mode or Cert Mode.
If you need a certificate for transport security, select Request for Certificate.
The Access System sends out a request for a certificate.
If you already have a certificate, select Install Certificate to install it.
Click Next.
If you selected Install Certificate, the AccessGate Configuration screen reappears.
You must provide the paths to the certificate, chain, and key files.
Note:
If the Installation fails unexpectedly or you need to change these settings later, you can run the configureAccessGate tool located in CWS_install_dir\oblix\tools\configureAccessGate, where CWS_install_dir is the directory where the Connector for WebSphere is installed.To supply the paths to the certificate files
Enter the full paths to the certificate, chain, and key files.
The certificate consists of these files. If necessary, click Browse to navigate to the location of these files.
Click Next to display the summary screen and then click Finish.
The installation is complete.
Next, if necessary, configure multiple WebPass instances for Connector for WebSphere.
Oracle Access Manager uses failover to maximize performance and provide uninterrupted service to end users. Failover redirects requests when a server fails. You may want to configure multiple WebPass instances for failover purposes.
This section assumes that you have already installed more than one instance of WebPass. See the Oracle Access Manager Deployment Guide for more information on failover.
To configure multiple WebPass instances for the Connector for WebSphere
Open the NetPointWASRegistry.properties file:
CWS_install_dir/oblix/config/NetPointWASRegistry.properties
where CWS_install_dir is the directory where you installed the Connector for WebSphere.
Enter the fully qualified host name with the domain name and port number for the WebPass using a comma-separated list as follows:
# IdentitySystem WebPass webserver host name and port number OB_WebPassHost=foo.domain.com,bar.doman.com OB_WebPassPort=81,80
In this example, the valid WebPass host:port combinations are:
foo.domain.com:81
bar.domain.com:80
Complete Connector setup as described next.
After installing the Connector for WebSphere, you must provide information about the Oracle Access Manager components that it communicates with, including the WebPass and Access Server.
Task overview: Completing Connector Setup
Complete your setup of the Connector, as described in "Setting Up the Connector for WebSphere".
Test the Connector environment, as described in "Testing Environment Setup".
In the following procedure, you ensure that the jar files added during installation appear in the proper location, or you add their location to the WebSphere classpath. You also ensure the environment variable path is correct. This is required because at run time, NetPointWASRegistry looks for the obaccess.dll file (Windows) or the libobaccess.so file (UNIX) that is located in the Oracle Access Manager installation directory.
To set up the Connector for WebSphere
Ensure that the following jar files that you added during installation exist in the directory WAS_install_dir/classes or add the location of these jar files to the WebSphere classpath:
NetPointWASRegistry.jar
jobaccess.jar
Add CWS_install_dir\oblix\lib to the environment variable path, as follows:
Solaris: In the setupCmdLine.sh file, add as follows:
CWS_install_dir\oblix\lib to $LD_LIBRARY_PATH
where CWS_install_dir is the directory where you installed the Connector for WebSphere.
Note:
The NetPointWASRegistry may fail to install if it can not find the Access Manager SDK. You may need to add the following environment variables to the setupCmdLine.sh: OBACCESS_INSTALL_DIR=CWS_install_dir.AIX: In setupCmdLine.sh file, add as follows:
CWS_install_dir\oblix\lib to $LIBPATH
Restart the WebSphere Administration Server.
Windows 2000: The installer automatically adds the information. However, you can:
Manually add CWS_install_dir\oblix\lib to the PATH System variable.
Reboot the machine.
Start the WebSphere Administration Server.
Check the configuration to ensure that WebGate is protecting the WebPass.
From the Access System Console, click Access System Configuration, click AccessGate Configuration in the left navigation pane, click the link for the WebGate that protects the WebPass, and in the IPValidation field select the Off option.
As of Oracle Access Manager 10.1.4, the WebGateStatic.lst file no longer exists. The options in this file have moved to the Access System Console. See Oracle Access Manager Access System Administration Guide for details.
Restart the Web server.
Verify the information in the NetPointWASRegistry.properties file located CWS_install_dir \oblix\config.
where CWS_install_dir is the directory where your Connector for WebSphere is installed. The file is populated with information that was specified during installation. For more information, see "NetPointWASRegistry.properties".
Determine if the machine hosting WebPass is running SSL, and if so, complete the following steps:
Open the NetPointWASRegistry.properties file and set OB_WebPassSSLEnabled = True.
Obtain the Web server and CA certificates of the Web server hosting WebPass or WebGate running in SSL mode and place them respectively in the server.cer file and the ca.cer file.
Use keytool in JAVA_HOME\bin or JAVA_HOME\jre\bin to add the following ca and server certificates to jssecacert keystore:
keytool -import -alias ca -file ca.cer -keystore jssecacert
keytool -import -alias server -file server.cer -keystore jssecacert
Depending on the Java version that you are using, copy this file to the security directory located in JAVA_HOME\lib\security, or in JAVA_HOME\jre\lib\security.
The Connector for WebSphere uses WebPass to make IdentityXML calls. You can specify only one WebPass at a time for the Connector for WebSphere. Typically, this will be on the same Web server that hosts the Policy Manager. If you have more than one WebPass, and want the Connector for WebSphere configured for a different WebPass, you can change the host machine and port in NetPointWASRegistry.properties file after installation.
If you edit the NetPointWASRegistry.properties file, you must restart the WebSphere Administration Server.
Note:
If WebPass is protected by a WebGate, ensure that the security level in this authentication scheme is the same level or a lower level than the one specified in the WebSphere authentication scheme discussed in "Defining an Authentication Scheme for WebSphere".Before you enable the NetPointWASRegistry, you need to run the registryTester program to ensure that the NetPointWASRegistry is registered and can successfully connect to the Identity System.
The following procedure applies to all WAS versions.
Note:
On Linux systems, ensure that the LD_ASSUME_KERNEL environment variable is set to 2.4.1.9, as follows:LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL
To run the registryTester program
Edit the file registerTester.bat (Windows) or registryTester.sh (UNIX) in the CWS_install_dir/unsupported directory.
where CWS_install_dir is the directory where you installed the Connector for WebSphere.
Modify these two variables as follows:
INSTALL_DIR: Specify the path to the Connector for WebSphere.
WAS_INSTALL_DIR: Specify the path to the WAS.
Specify the correct classpath and comment out the unused classpath for your installation:
WebSphere 5.0 with Connector 7.0: Keep WebSphere classpath for v5.0; comment out irrelevant WebSphere classpaths.
WebSphere 5.0.2: Keep WebSphere classpath for v5.0.2; comment out irrelevant WebSphere classpaths.
WebSphere 5.1 with Connector 7.0.2: Keep the WebSphere classpath for v5.1; comment out irrelevant WebSphere classpaths.
WebSphere 6.0 with Connector 7.0.4: Keep the WebSphere classpath for v5.1; comment out irrelevant WebSphere classpaths.
If you do not have a JAVA_HOME environment variable defined, set the JAVA_HOME parameter value as follows in the registryTester.bat or registryTester.sh file:
Windows: %JAVA_HOME% = WAS_install_dir \java
UNIX: $JAVA_HOME$ = WAS_install_dir /java
where WAS_install_dir is the directory where you installed WebSphere.
WebSphere 5.x only: Update the registryTester.sh (.bat on Windows) as follows:
set CLASSPATH=.:${CLASSPATH}:${INSTALL_DIR}/oblix/lib/NetPointWASRegistry.jar:${INSTALL_DIR}/oblix/lib/jobaccess.jar:${WAS_INSTALL_DIR}/lib/xerces.jar:${WAS_INSTALL_DIR}/lib/j2ee.jar:${WAS_INSTALL_DIR}/lib/wssec.jar:${WAS_INSTALL_DIR}/java/jre/lib/ext/ibmjsse.jar
Note:
You may check the registryTester.bat for details.From the command line, run registryTester:
NT/W2K: registryTester.bat
UNIX: registryTester.sh
Supply a Oracle Access Manager user ID and password when prompted.
Verify the result:
If the program completes successfully, it connects to the Identity Server and returns a list of groups to which the user belongs.
If the registryTester program fails to connect with the Access Server or the Identity Server, check the parameter values in the NetPointWASRegistry.properties file and correct them as needed.
The following sections describe the integration of Oracle Access Manager with the WebSphere Application Server v5.0 or 5.1.
Before you begin, see "Supported Versions and Platforms" for complete details about version support.
Task overview: Integrating with WAS v5
Enable the registry, as described in "Enabling the NetPointWASRegistry in WAS v5".
Test the configuration, as described in "Testing the NetPointWASRegistry for WebSphere v5".
Configure the TAI, as described in "Configuring the TAI for WebSphere v5".
Once you have installed the products and tested them to be sure they are communicating, you can enable the NetPointWASRegistry. Enabling the registry causes Oracle Access Manager to be used as the authentication source for the WebSphere Application Server.
The NetPointWASRegistry works with the User Registry in WebSphere 5.
Note:
In the following procedure, any Identity System user who is added to the role "Admin" must be in a group called "Admin" or "Administrator". Otherwise, this user may not able to login to WebSphere Administrative Console. Other roles, like "monitor" have no restrictions. Any Identity System user added to these roles in the WAS 5 Administrative Console can log in to the WAS 5 Administrative Console.To enable the NetPointWASRegistry in WAS 5
On Linux systems, ensure that the LD_ASSUME_KERNEL environment variable is set to 2.4.19 in the following location:
WAS_install_dir/bin/setupCmdLine.sh
Use the following command to set the environment variable:
LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL
Ensure that WebGate protecting the WebPass has IPValidation set to Off.
From the Access System Console, click Access System Configuration, click AccessGate Configuration in the left navigation pane, click the link for the WebGate that protects the WebPass, and in the IPValidation field select the Off option.
Create a backup copy of security.xml.
In the following step, you will modify the configuration. You need to create a backup copy of security.xml before making a change to the configuration. If there are errors in the new configuration, you can always restore the previous version of the security.xml file.
Copy the security.xml file located in the following directory:
WAS_install_dir/config/cells/serverName
Start the WebSphere Admin Service.
Log in as the Identity Administrator into the WebSphere Administrative Console.
Navigate to Security, User Registries, Custom Properties and enter the following:
Identity Administrator user ID
Server User Password
CustomRegistry Classname
Identity System Admin ID
User's password
Oracle Access Manager Classname: com.oblix.registry.NetPointWASRegistry
Under Additional Properties in the Configuration tab, click Custom Properties, click New, and enter the following:
Name: NetPointWASRegistry.properties
Value: C:\CWS_install_dir\oblix\config\NetPointWASRegistry.properties.
Description: Property file for Oracle Access Manager User Registry.
Select the Required checkbox, click OK, and save your changes.
In the navigation pane on the left, click Authentication Mechanism, LTPA.
In the Configuration tab, specify a password.
Click OK.
Navigate back to LTPA (in the navigation pane on the left, click Authentication Mechanism, LTPA) and do the following:
Click Single Signon (SSO).
Click the Enabled box.
Enter the domain name. For example, .oracle.com.
Click OK.
In the navigation pane on the left, click Security, Global Security and change the following:
Set the Active Authentication Mechanism to LTPA.
Set the Active User Registry to Custom.
Click OK.
Click the Enabled box.
Click Apply to test the configuration.
If the information is correct, a message confirming the changes is displayed at the top. Correct any errors that are displayed.
Click Save.
Click Logout and close the browser window.
Stop the WebSphere Application Service.
If you get a message stating that the Service could not be stopped, switch to the Task Manager and ensure that there are no java processes running.
Start the WebSphere Admin Service.
Next, verify the NetPointWASRegistry is configured correctly.
To test the NetPointWASRegistry configuration
Access the Snoop Servlet sample running on the default server at
http://hostname:port/snoop
or
http://hostname:web_server_plug-in_port/snoop
When challenged by WebSphere, enter a username and password that is valid in Oracle Access Manager.
By default, any authenticated user should be allowed access.
Launch the WebSphere Administrative Console and login as the user specified in Security, User Registries, Custom Properties.
If the configuration is correct, you will be able to login successfully.
Set access control for the WebSphere Administrative Console by specifying the users and groups and the roles to which they belong.
See WebSphere 5 documentation for more information.
Note the .xml files that are modified to support Admin Console access and click Save.
After you have installed Connector for WebSphere, you must configure the NetPointWASRegistry and TAI. The NetPointWASRegistry is used for authentication and the TAI enables single sign-on using Oracle Access Manager.
You configure the TAI to enable single sign-on between Oracle Access Manager and WAS, as well as between Oracle Access Manager and the WebSphere Portal Server. For WebSphere 5.0 or 5.1, you must install webgate.properties, add the TAI, and then add custom properties.
Note:
On Linux systems, ensure that the LD_ASSUME_KERNEL environment variable is set to 2.4.19 in the corresponding WebServer startup script, as follows:LD_ASSUME_KERNEL=2.4.19
export LD_ASSUME_KERNEL
Tip:
For optional details, see "Implementation Notes for the TAI".To install and configure TAI for WAS 5
Copy the configuration file named webgate.properties (see Table 11-2 for parameters):
From: CWS_install_dir /oblix/config
To: WAS_install_dir /properties folder in the WebSphere installation properties directory.
where CWS_install_dir is the directory where the Connector for WebSphere is installed, and WAS_install_dir is the directory where the WebSphere Application Server is installed.
This file contains configuration information that WebSphere will use to connect to the AccessGate.
In the WebSphere installation properties directory, modify the parameter values of the webgate.properties file (See Table 11-2) as follows:
OB_InstallDir = CWS_install_dir
where CWS_install_dir is the directory where the Connector for WebSphere is installed. For example:
C:\COREid\NetPointWASRegistry
If WebGate is installed on a proxy server that is used as a front end server to direct all user requests to Web servers that interface with WebSphere Application Servers, then specify the following parameter values:
OB_IsProxyEnabled=true
OB_hostnames = serverName
where serverName is the name of the proxy server.
OB_ports = portNumber
where portNumber is the port number of the proxy server.
Note:
If you used a resource other than Authen, you must specify the resource name in the webgate.properties file.Launch the WebSphere Administrative Console.
In the navigation pane on the left, click Authentication Mechanisms, LTPA.
Under Additional Properties, click Trust Association, Interceptors, New.
In the Name field, enter Oracle TAI Interceptor.
In the Interceptor classname field, enter com.oblix.tai.was5.WebGateTrustAssociationInterceptor.
Click OK.
Add the following three properties:
Name: com.ibm.websphere.security.trustassociation.types
Value: webgate
Description: TAI property
Select the Required checkbox.
Click OK.
Name: com.ibm.websphere.security.trustassociation.webgate.config
Value: webgate
Description: Name of the TAI properties file located in WAS_install_dir/properties directory.
Select the Required checkbox.
Click OK.
Name: com.ibm.websphere.security.trustassociation.webgate.interceptor
Value: com.oblix.tai.was5.WebGateTrustAssociationInterceptor
Description: TAI class for WebSphere 5
Select the Required checkbox.
Click OK.
Click Interceptors at the top of the page and then click Save.
Navigate to:
WAS_install_dir /config/cells/serverName_dir
where serverName_dir is the directory where the server is installed.
Make a backup copy of the security.xml file.
In the WebSphere Administrative Console, navigate to LTPA, Trust Association, Interceptors.
Select the WebSeal Interceptor and click Delete.
Click Trust Association and click the Enabled check box.
Click Apply and then click Save.
Logout of the WebSphere Administrative Console and close the browser.
Shut down the Websphere Admin Server.
If you get an error message, go to Task Manager and ensure that the java process is not running.
Restart the WebSphere Admin Service.
If the Service does not start, verify that the properties are set correctly in the security.xml file and that the webgate.properties file is in the correct location.
Create an Access System policy to protect WebSphere resources
In the Policy Manager, define a policy for the resource that you want to protect.
Other authorization rules can also be added at this point. The policy that you use to protect the URL can use basic, form, cert, or other authentication schemes that the Access System supports.
Ensure that the security level in this authentication scheme is equal or greater than the one specified in the WebSphere authentication scheme discussed in "Preparing Your Environment".
See the Oracle Access Manager Access System Administration Guide for more information on defining policies.
Verify that the TAI is working as detailed in the following section.
After you have configured TAI, restart WAS and test for successful authentication and single sign-on between WebSphere and Oracle Access Manager.
To conduct these tests, you use the Snoop servlet that WebSphere provides. The Snoop servlet has security constraints that only allow access to authenticated users. When WebSphere security is not enabled, access to the Snoop is unrestricted. When WebSphere security and TAI are enabled, users attempting to access Snoop will be challenged by the Access System. If TAI is not enabled, users attempting to access Snoop will be challenged by WebSphere.
To test Access System single sign-on for WAS, you must build and configure a new WebSphere secure application. Then, test Access System authentication and single sign-on for the secured application.
During installation, a secure application is built that you can use for testing and stored in the following location:
CWS_install_dir/examples/securityapp/SimpleSessionSecure.ear
where CWS_install_dir is the directory where you installed the Connector.
Note:
If you wish, you can build your own secure application. The following procedure describes how to build an application for WAS 5.x.To build a WebSphere secure application
Build a secure application named SimpleSessionSecure according to the instructions available at the following URL:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/ infocenter/was/060704_security.html
Save the SimpleSessionSecure.ear file in the appropriate location; for example, in c:\temp.
Verify that the WAS Administration Server is running.
To install the SimpleSessionSecure application
Launch the WebSphere Administrative Console located in WAS_install_dir \bin\adminclient.
where WAS_install_dir is the directory where the WebSphere Application Server is installed.
In the WebSphere Console tree view, right-click WebSphere Administrative Domain, Enterprise Applications.
From the resulting menu, click Install Enterprise Application to launch the Install Enterprise Application wizard.
The Specifying the Application or Module panel appears.
Verify the following settings:
The Browse for file on node field is set to your current node.
The Install Application option is selected.
Click Browse to locate and select the SimpleSessionSecure.ear file.
Verify that its name is now displayed in the Path field and specify SimpleSessionSecure as the Application name.
Click Next, then click Yes when prompted whether to deny access to unprotected methods.
In the Mapping Users to Roles panel, verify that the Goodguys role is mapped to valid Identity System Users.
Click Select; verify that Identity System Users are listed in the Selected Users/Groups area of the resulting Select Users/Groups dialog, then click OK to close the dialog after verification.
Click Next.
On the Mapping EJB RunAs Roles to Users panel, click Next.
In the Binding Enterprise Beans to JNDI Names panel, verify that the JNDI Name is set to gs/hello, and then click Next.
In the Mapping EJB References to Enterprise Beans panel, verify that the JNDI Name is set to gs/hello, and then click Next.
Click Next in the next three panels, until the Selecting Virtual Hosts for Web Modules panel appears.
In the Selecting Virtual Hosts for Web Modules panel, ensure that the Virtual Host is set to default_host, then click Next.
In the Selecting Application Server panel, ensure that the EJB11 and SimpleSessionWar modules reside on Application Server named Default Server and then click Next.
In the Completing the Application Installation Wizard panel, click Finish.
When prompted to regenerate code, click No.
Look for the message confirming successful installation of the application
It may be a minute before it is displayed. You can now view the SimpleSessionSecure application in the WebSphere Administrative Console tree view.
After you build the SimpleSessionSecure application, regenerate the plug-in configuration to enable the Web server to locate the WebSphere application.
To regenerate the plug-in configuration
In the console tree view, right-click WebSphere Administrative Domain, Nodes, hostname.
Where hostname is the name of the machine where WebSphere is installed.
From the resulting menu, select Regen Webserver Plugin.
In the Event Message panel, a message appears stating that the plug-in regeneration has been completed.
Stop the WebSphere Administrative Server and start it again:
To stop the administrative server, under Nodes in the WebSphere Administrative Console, right-click hostname and select Restart from the resulting menu. The console will close.
Open the WebSphere Administrative Console again after the administrative server starts.
This time, you will be asked to log in, because security is enabled.
In the WebSphere Administrative Console tree view, click WebSphere Administrative Domain, Nodes, hostname, Application Servers, Default Server.
Where hostname is the fully qualified name of the machine where WebSphere is installed; for example, xyz.domain.com.
Ensure that the Module Visibility setting of the Default Server is set to Compatibility.
If you want to change the visibility setting, click Apply.
To test Access System authentication and single sign-on
Access the SimpleSessionSecure application at the following URL:
http://hostname/gettingstarted3/SimpleSession?msg=Hi
where hostname is the fully qualified name of the machine where WebSphere is installed; for example, xyz.domain.com.
Log in as a Oracle Access Manager user.
TAI Not Enabled: If you have not enabled the TAI, you will be challenged by WebSphere and your credentials are passed on to the Access System. After the Access System authenticates you, you will be allowed to access SimpleSessionSecure.
TAI Enabled: If you have enabled TAI, you will be challenged and authenticated by the Access System. Because single sign-on between the Access System and WAS is enabled, you are allowed to access SimpleSessionSecure and other Access System-protected resources (URLs) without being challenged by WebSphere.
To test single sign-on for Access System-protected WebSphere resources
On the Web server you use to access the WAS, navigate to the document root and create a directory named test.
In the test directory, create a file named index.html.
In the Access System, create and enable policies to protect /servlet and /test directories.
Access the Snoop servlet at the following URL:
http://hostname.domain.com:9080/servlet/snoop
where hostname is the fully qualified name of the machine where WebSphere is installed; for example, xyz.domain.com.
You will be challenged for authentication. After you are authenticated, you will be allowed to access the Snoop servlet.
Access the /test URL.
You must be allowed to access the URL and view the index.html file without being challenged.
You can enable logging for the TAI from the WebSphere Administrative Console. The procedure to enable logging varies depending on the WAS version that you use.
To enable logging for TAI for WAS 5
Launch the WebSphere Administrative Console.
Navigate to Troubleshooting, Logs and Trace
Select your Server.
Select Diagnostic Trace.
Modify the Trace specification.
Select the Components tab.
Enable debug logging for com.oblix.tai.was5.WebGateTrustAssociationInterceptor.
Integrate Oracle Access Manager with the WAS Portal v5, if desired.
The following sections describe how you integrate Oracle Access Manager with the WebSphere Application Server v6:
You can find support and certification information at the following URL:
http://www.oracle.com/technology/documentation/
You must register with OTN to view this information.
Also, you can see the supported versions and platforms for this integration on Metalink, as follows.
To view information on Metalink
In your browser, enter the following URL:
Log in to MetaLink.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Identity Manager and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, Oracle Access Manager Certification to display the certification matrix.
After you have installed WAS 6 or 6.1 and the Connector for Websphere, then tested them to be sure they are communicating, you can enable the NetPointWASRegistry, which interoperates with the User Registry in WebSphere 6 and 6.1. This enables Oracle Access Manager to act as the authentication source for the WebSphere Application Server.
Notes:
The procedures for WAS 6 and 6.1 are slightly different.In the following procedures, any Oracle Access Manager user who is added to the role "Admin" must belong to the group named "Admin" or "Administrator." Otherwise, this user may not able to log in to WebSphere Administrative Console. Other roles, such as "Monitor" have no restrictions. Any Oracle Access Manager user added to these roles through the WAS 6 or 6.1 Administrative Console can log in to the WAS 6 or 6.1 Administrative Console.
To enable the NetPointWASRegistry in WAS 6
Ensure that WebGate protecting the WebPass has IPValidation set to Off.
From the Access System Console, click Access System Configuration, click AccessGate Configuration in the left navigation pane, click the link for the WebGate that protects the WebPass, and in the IPValidation field select the Off option.
Make a backup copy of the security.xml file located in the following directory:
WPS_install_dir/profiles/default/config/cells/serverNodeName
Create a backup copy of security.xml whenever you make a change to the configuration. If you make errors in the new configuration, you can restore from backup.
Start the WebSphere Admin Service.
Log in to the WebSphere Administration Console as the WebSphere administrator.
The Administrative Console for WAS 6 is accessible through the following URL:
http://hostname.domain.com:9060/ibm/console
where hostname is the fully qualified name of the machine where WebSphere is installed; for example, xyz.domain.com.
In the left navigation pane, click Security, then click Global Security, and do the following:
Uncheck the Enable Global Security checkbox, click Apply, click Save, then log out an close the browser window.
Stop the WebSphere Application Service.
If a message announces that Service could not be stopped, switch to the Task Manager and ensure that no Java processes are currently running.
Restart WebSphere and log in to the WebSphere Administration Console as the Identity administrator.
Navigate to Security, Global Security, Custom and enter values for the following variables:
Server user ID
Server User Password
CustomRegistry Classname
Oracle Access Manager Admin ID
User password
Oracle Access Manager Classname: com.oblix.registry.NetPointWASRegistry
Navigate to Configuration, Additional Properties, Custom Properties, New.
Enter values for the following parameters:
Name: NetPointWASRegistry.properties
Value: /opt/netpoint/oblix/config/NetPointWASRegistry.properties
Description: Property file for User Registry
Click Apply.
Navigate to Global Security, Authentication Mechanisms, LTPA.
In the Configuration tab, specify a password, then click Apply.
Click Single Signon (SSO).
Click the Enabled box.
Enter the domain name (for example, oracle.com)., then click Apply.
In the left navigation pane, click Security, click Global Security, then complete the following steps:
Set the Active Authentication Mechanism to LTPA.
Set the Active User Registry to Custom User Registry, then click OK.
Click the Enable Global Security box.
Click Apply to test the configuration.
If the information is valid, a message confirming the changes displays at the top. Otherwise, correct any errors that are reported.
Click Save.
Click Logout and close the browser window.
Stop the WebSphere Application Service. If a message announces that Service could not be stopped, switch to the Task Manager and ensure that no Java processes are currently running.
Start the WebSphere Administration Service.
To enable the NetPointWASRegistry in WAS 6.1
Ensure that WebGate protecting the WebPass has IPValidation set to Off.
From the Access System Console, click Access System Configuration, click AccessGate Configuration in the left navigation pane, click the link for the WebGate that protects the WebPass, and in the IPValidation field select the Off option.
Make a backup copy of the security.xml file located in the following directory:
WPS_install_dir/profiles/default/config/cells/serverNodeName
Create a backup copy of security.xml whenever you make a change to the configuration. If you make errors in the new configuration, you can restore from backup.
Start the WebSphere Admin Service.
Log in to the WebSphere Administration Console as the Identity Administrator.
The Administrative Console for WAS 6 is accessible through the following URL:
http://hostname.domain.com:9060/ibm/console
where hostname is the fully qualified name of the machine where WebSphere is installed; for example, xyz.domain.com.
Navigate to Security, then to Secure administration, applications, and infrastructure, and in the Available realm definitions section select Standalone Custom Registry, click Configure, and enter the following under General Properties.
Primary administrative user name: Enter oam_administrator_ID, where the value is an Oracle Access Manager administrator ID.
Server user identity: Select the Automatically generated user identity option.
Custom registry class name: com.oblix.registry.NetPointWASRegistry
Check the Ignore Case for Authorization checkbox.
Click Apply.
Navigate to Additional Properties, Custom Properties, New, and enter values for the following parameters:
Name: NetPointWASRegistry.properties
Value: /opt/netpoint/oblix/config/NetPointWASRegistry.properties
This is the full path to the NetPointWASRegistry.properties file.
Description: Property file for User Registry
Click Apply.
Navigate to Security, then to Secure Administration, applications, and infrastructure, then to Web Security.
Click Single sign-on (SSO), and enter the following under General Properties:
Click the Enabled box.
Enter the domain name (for example, mycompany.com).
Click Apply.
Go to Security, then to Secure Administration, applications, and infrastructure, and do the following:
Under Administrative Security, click the Enabled administrative security box.
Under Application security, click the Enable application security box.
In the Available Realm Definition list, select Standalone Custom Registry and click the Set As Current button.
Click Apply to test the configuration.
If the information is valid, a message confirming the changes displays at the top. Otherwise, correct any errors that are reported.
Click Save.
Click Logout and close the browser window.
Stop the WebSphere Application Service.
If a message announces that Service could not be stopped, switch to the Task Manager and ensure that no Java processes are currently running.
Start the WebSphere Administration Service.
After you have enabled the NetPointWASRegistry, you need to verify that it is configured correctly.
To test the NetPointWASRegistry configuration
Access the Snoop Servlet sample running on the default server at the following URL:
http://hostname:9080/snoop
Where hostname is the fully qualified name of the machine where WebSphere is installed.
Alternatively, you can use the following URL:
http://hostname:web_server_plug-in_port/snoop
Where hostname is the fully qualified domain name of the machine on which WebServer is installed.
When challenged by WebSphere, enter a username and password that is valid in Oracle Access Manager.
By default, any authenticated user should be allowed access.
Launch the WebSphere Administrative Console and login as the user specified in Security, Global security, Custom.
If the configuration is valid, the login will succeed.
Set access control for the WebSphere Administrative Console by specifying the users and groups and the roles to which they belong.
See WebSphere 6 documentation for details.
Write down the names of the .xml files that you have modified to support Admin Console access, then click Save.
After you have installed Connector for WebSphere, you must configure the NetPointWASRegistry and TAI. The NetPointWASRegistry handles authentication, and the TAI facilitates Access System single sign-on.
You configure the TAI to enable single sign-on between Oracle Access Manager and WAS. For WebSphere 6.0 or 6.1 you must install webgate.properties, add the TAI, and then add custom.properties.
Note:
The procedures for configuring the TAI are slightly different for WAS 6 and 6.1.To install and configure TAI for WebSphere v6
Copy the configuration file webgate.properties from the following directory:
CWS_install_dir/oblix/config
where CWS_install_dir is the directory where the Connector for WebSphere is installed, to the WebSphere installation properties directory, which resides in the following location:
WAS_install_dir/properties
where WAS_install_dir is the directory where the WebSphere Application Server is installed.
Webgate.properties contains configuration information that WebSphere will use to connect to the AccessGate.
In the WebSphere installation properties directory, modify the parameter values in the webgate.properties file as follows:
OB_InstallDir = CWS_install_dir
where CWS_install_dir is the directory where the Connector for WebSphere is installed.
If the associated WebGate is installed on a proxy server used as a front end server to direct all user requests to Web servers that interface with WebSphere Application Servers, then specify the following parameter values:
OB_IsProxyEnabled=true
OB_hostnames = serverName
where serverName is the name of the proxy server.
OB_ports = portNumber
where portNumber is the port number of the proxy server.
Note:
If you used a resource other than Authen, you must specify the resourcename in thewebgate.properties file.Launch the WebSphere Administrative Console.
In the navigation pane on the left, navigate to Global security, Select Authentication Mechanisms, LTPA, Trust Association, Additional Properties, Interceptors, New.
In the Interceptor classname field, enter com.oblix.tai.was5.WebGateTrustAssociationInterceptor, then click Apply.
Navigate to Additional Properties, then to Custom Properties, then to New.
Make the following changes:
Name: com.ibm.websphere.security.trustassociation.types
Value: webgate
Description: TAI property
Click OK.
Name: com.ibm.websphere.security.trustassociation. webgate.config
Value: webgate
Description: Name of the TAI properties file located in WAS_install_dir/properties directory.
Click OK.
Name: com.ibm.websphere.security.trustassociation. webgate.interceptor
Value: com.oblix.tai.was5. WebGateTrustAssociationInterceptor
Description: TAI class for WebSphere 6
Click OK.
Click Interceptors at the top of the page and then click Save.
Navigate to the following:
WAS_install_dir/profiles/default/config/cells/serverNodeName
Make a backup copy of the security.xml file.
In the WebSphere Administrative Console, navigate to LTPA, Trust Association, Interceptors.
Select the WebSeal Interceptor, then click Delete.
Click Trust Association, then click the Enable Trust Association check box.
Click Apply, then click Save.
Logout of the WebSphere Administrative Console, then close the browser.
Shut down the Websphere Admin Server.
If you get an error message, go to Task Manager and ensure that no Java process is running.
Restart the WebSphere Admin Service.
If the Service does not start, verify that the properties are set correctly in the security.xml file and that the webgate.properties file is in the correct location.
Create an Access System policy to protect WebSphere resources as described in "To install and configure TAI for WAS 5".
To facilitate access the Administration Console after you have enabled TAI, you need to enable the Policy created in "Defining a Policy Domain for WebSphere". You also need to enable the policy created in "Defining a Policy Domain for the WebSphere v6.0 Administration Console".
Verify that the TAI is working, as detailed in "Testing the TAI for WAS 6 and 6.1".
To install and configure TAI for WAS 6.1
Copy the configuration file webgate.properties from the following directory:
CWS_install_dir/oblix/config
where CWS_install_dir is the directory where the Connector for WebSphere is installed, to the WebSphere installation properties directory, which resides in the following location:
WAS_install_dir/properties
where WAS_install_dir is the directory where the WebSphere Application Server is installed.
Webgate.properties contains configuration information that WebSphere will use to connect to the AccessGate.
In the WebSphere installation properties directory, modify the parameter values in the webgate.properties file as follows:
OB_InstallDir = CWS_install_dir
where CWS_install_dir is the directory where the Connector for WebSphere is installed.
If the associated WebGate is installed on a proxy server used as a front end server to direct all user requests to Web servers that interface with WebSphere Application Servers, then specify the following parameter values:
OB_IsProxyEnabled=true
OB_hostnames = serverName
where serverName is the name of the proxy server.
OB_ports = portNumber
where portNumber is the port number of the proxy server.
Note:
If you used a resource other than Authen, you must specify the resourcename in thewebgate.properties file.Launch the WebSphere Administrative Console.
Go to Security, then to Secure Administration, applications, and infrastructure, then to Web Security.
Click Trust Association, then click Additional Properties, then click Interceptors, then click New.
In the Interceptor classname field, enter com.oblix.tai.was5.WebGateTrustAssociationInterceptor, then click OK.
Click com.oblix.tai.was5.WebGateTrustAssociationInterceptor, then click Additional Properties – Custom Properties, then click New.
Add the following custom properties:
Name: com.ibm.websphere.security.trustassociation.types
Value: webgate
Description: TAI property
Click OK.
Name: com.ibm.websphere.security.trustassociation. webgate.config
Value: webgate
Description: Name of the TAI properties file located in WAS_install_dir/properties directory.
Click OK.
Name: com.ibm.websphere.security.trustassociation. webgate.interceptor
Value: com.oblix.tai.was5. WebGateTrustAssociationInterceptor
Description: TAI class for WebSphere 6
Click OK.
Click Interceptors at the top of the page and then click Save.
Navigate to the following:
WAS_install_dir/profiles/default/config/cells/serverNodeName
Make a backup copy of the security.xml file.
Go to Security, then to Secure Administration, applications, and infrastructure, then to Web security.
Click Trust Association, then click Additional Properties, then click Interceptors.
Delete the following Interceptors:
com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl
com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus
com.ibm.ws.security.web.WebSealTrustAssociationInterceptor
com.ibm.ws.sip.security.digest.DigestTAI
Click Trust Association, then click the Enable Trust Association check box.
Click Apply, then click Save.
Logout of the WebSphere Administrative Console, then close the browser.
Shut down the Websphere Admin Server.
If you get an error message, go to Task Manager and ensure that no Java process is running.
Restart the WebSphere Admin Service.
If the Service does not start, verify that the properties are set correctly in the security.xml file and that the webgate.properties file is in the correct location.
Create an Access System policy to protect WebSphere resources as described in "To install and configure TAI for WAS 5".
To facilitate access the Administration Console after you have enabled TAI, you need to enable the Policy created in "Defining a Policy Domain for WebSphere". You also need to enable the policy created in "Defining a Policy Domain for the WebSphere v6.0 Administration Console".
Verify that the TAI is working, as detailed in "Testing the TAI for WAS 6 and 6.1".
The following procedure describes testing the TAI for WAS 6 and 6.1.
After you have configured TAI, test for successful authentication and single sign-on between WebSphere and Oracle Access Manager.
To conduct these tests, use the Snoop servlet that WebSphere provides. The Snoop servlet has security constraints that only allow access to authenticated users.
When WebSphere security is not enabled, access to the Snoop is unrestricted.
When WebSphere security and TAI are enabled, users attempting to access Snoop will be challenged by the Access System. If TAI is not enabled, users attempting to access Snoop will be challenged by WebSphere as well.
To test single sign-on for Access System-protected WebSphere resources
On the Web server you use to access the WAS, navigate to the document root and create a directory named test.
In the test directory, create a file named index.html.
In the Access System, create and enable policies to protect the /snoop and /test directories.
Access the Snoop servlet through the following URL:
http://hostname.domain.com:80/snoop
where hostname is the fully qualified name of the machine where the Web server is installed.
You will be challenged for authentication. After you are authenticated, you will be allowed to access the Snoop servlet.
Access the /test URL.
Verify that you can access the URL and view the index.html file without being challenged.
You can enable logging for TAI from the WebSphere Administrative Console.
To enable logging for TAI for WAS 6 and 6.1
Launch the WebSphere Administrative Console.
Navigate to Troubleshooting, Logs and Trace
Select your Server.
Select Change Log Level Details.
Select Components.
Enable debug logging for com.oblix.tai.was5.WebGateTrustAssociationInterceptor
A portal provides a single point of access to enterprise data and applications, presenting a unified and personalized view of that information to employees, customers, and business partners.
The WebSphere Portal Server runs on top of the WAS and uses the WAS security infrastructure to enforce access control. Integrating Oracle Access Manager with the WebSphere Portal provides the following Oracle Access Manager functionality for the portal:
User and group management
Password management
SSO to the portal
Unified logout between Oracle Access Manager, WAS, and the WebSphere Portal
The WebSphere Portal V5 uses the following component to manage user and group information.
Member Manager: Member Manager presents a Java object view of Users and Groups to WebSphere Portal, including all portlets installed on WebSphere Portal. Member Manager (as accessed through PUMA) is the abstraction interface that WebSphere Portal V5.0 uses to access user and group information. This includes the user accounts, which tell Portal that the user exists, any user groups within which the user might be a member, and attributes about the users.
The following figure shows the architecture of the Member Manager.
See the WebSphere Portal v5 documentation for more information on the portal and related components.
Oracle Access Manager Custom Member Repository: The Custom Member Repository (CMR) is available with the Connector for WebSphere, as described in "Supported Versions and Platforms". The CMR is an instance of a Member Manager component that connects the WebSphere Portal Server to the Identity System users and groups.
The CMR is a custom user data store that implements the IBM WebSphere MemberRepository interface. As shown in Figure 11-4, the CMR stores user and group base attributes in user data store. The CMR is used by the WebSphere Portal Server to make queries like getAttributes for a user for personalization, getGroupMemberships, search users by attribute, and similar functions. User profile information is in the Portal database and authentication information is available through the Administration Console and LDAP.
Note:
Group MemberShip functionality is not currently supported. As a result, with Nested Groups, if you check for inner group membership it won't display its parent group details.The CMR supports only read operations, not create, modify, or delete operations. The CMR is an extension of the custom user registry (CUR) and requires the Portal Server.
The configuration files used to control WebSphere Portal Member Manager come into play with the CMR are explained in the following paragraphs. These files are usually created during the portal installation:
wmm.xml: Top level Member Manager configuration. Lists and configures the various MemberRepository implementations used by Member Manager. Most other Member Manager configuration files are pointed to from this file. The CMR details should be configured in this file.
PumaService.properties: This is the configuration file for the PUMA API, which in WebSphere Portal V5.0.x is a mapping layer between WebSphere Portal and Member Manager. This is not a Member Manager configuration file, but because PUMA is part of the "user stack" in Portal, this configuration file is important.
This file includes a comma-separated list of attribute names that will be passed to Member Manager requests and several multi-valued properties. This file may need to be configured for the user attributes for personalization. All user.base.attributes and group.base.attributes values will be searchable in the CMR. For example:
user.base.attributes=cn,uid,cn,logonId,logonPasswordVerify,logonPassword ... group.base.attributes=cn,uniqueOwnerIdentifier,membergroups, groupmembers,memberGroupName,memberGroupType,distinguishedName
All other attributes go to the Portal database.
During startup, only the attributes identified in the user.minimum.attributes parameter are retrieved. For example:
user.minimum.attributes=cn,genUserid,cn,givenName,sn,mail
Note:
All attributes in the user.minimum.attributes list must have correct attribute access control set in the User Manager and Group Manager for the Administrator, and all need to be in one of the User Manager configuration panels. For example, if the Portal Server needs the givenName attribute, one of the Identity System panels needs First Name. In the Identity System, the givenName attribute is mapped to Display Name, First Name.To see the LDAP to Oracle Access Manager mapping, you can select the desired attribute and view the corresponding Display Name in the Identity System Console, User Manager Configuration, Configure Tab, Link, Modify Attributes page.
See the Oracle Access Manager Identity and Common Administration Guide for details.
wpconfig.properties: This is WebSphere Portal configuration file. The portal user/group administrator details needs to be set in this file. This file is present in WPS_install_dir/config folder, where WPS_install_dir is the Portal Server home directory.
VaultService.properties: This file is located in WPS_install_dir /shared/app/config/services folder. This configuration file is used to specify Vault Adapter Implementations. You have to set correct system admin credential DN in this file.
During login, the user is authenticated as depicted in "Scenario 1: Use of NetPointWASRegistry".
Without the Oracle Access Manager CMR, the WebSphere Portal Server must communicate directly with the LDAP directory server to obtain user, group, and personalization information. With the CMR, communication between the WebSphere Portal Server and the directory server can be eliminated. The CMR performs read operations through the NetPointWASRegistry with the directory server.
Figure 11-5 shows the interaction between the WebSphere Portal Server, CMR, and LDAP directory server during the login authorization process. This follows processes described in "Scenario 1: Use of NetPointWASRegistry".
Process overview: Authorization with the CMR
For instance, the Access Manager SDK uses the checkPassword method while IdentityXML uses all other methods:
After authentication, a user requests access to a portlet through the WebSphere Portal Server.
The Portal Server forwards the request to the CMR.
The CMR forwards the request to the NetPointWASRegistry.
The NetPointWASRegistry sends an IdentityXML call to the Identity Server or uses the Access Manager SDK to contact the Access Server through WebPass or WebGate, depending upon the required method.
findByAttribute to search users by attribute
getMember
getGroupMemberIdentifiers
getMembers
search etc.
The Identity Server (or Access Server) communicates with the LDAP directory server.
The directory server returns information.
Integrating the WebSphere Portal v5 with Oracle Access Manager involves a series of installation and configuration tasks.
To integrate the WebSphere Portal with Oracle Access Manager
Complete tasks in "Preparing to Install the Connector":
Install the WebSphere Application Server with appropriate Fix Pack as described in the WebSphere documentation to correct the following issues.
For example:
Issue: Access permissions to portlets do not work if the user dn contains intermediate spaces after a comma, for example:
Cn=PortalUser, o=company, c=us
IBM has released a Fix PQ93461 for this Portal User access permission problem.
Action: This fix pack needs to be applied. Verify the Portal Server History Log to ensure that all required fixes have been installed. Refer to the Portal Infocenter document for details.
Install the WebSphere Portal with WebSphere Application Server security disabled.
Note:
Both the Global and Java 2 security should be disabled while installing the Portal Server.See the IBM WebSphere Portal Infocenter document for details.
Install and configure Oracle Access Manager, as discussed in "Preparing to Install the Connector".
Install the Connector for WebSphere and configure the NetpointWASRegistry and TAI components, as described in "Installing the Connector for WebSphere".
Complete Connector setup and testing, as discussed in "Completing Connector Setup".
In the WebSphere Administration Console, change security to custom registry.
This specifies the NetPointWASRegistry, which establishes a connection between the WAS and Oracle Access Manager. The WAS uses the NetPointWASRegistry to authenticate and authorize portal users with the Access System's security policies.
Ensure that the following Admin credentials are set in clear text in the NetPointWASRegistry.properties file:
OB_AdminUserName=admin OB_AdminUserCreds=password
Where the OB_AdminUserName value is the user ID of the Portal Server administrator who is a Master Administrator or a Master Identity Administrator.
This is required for the CMR. The Admin credentials should be set in clear text. The NetPointWASRegistry reads the password, encrypts it, and rewrites the properties file with the encrypted password. The encryptor can be executed by running the registryTester program, as well as from WebSphere. To assist you with adding these parameters, see the NetPointWASRegistryProperties.sample file, which includes comments. See also, "NetPointWASRegistry.properties".
Note:
The formatting of NetPointWASRegistry.properties is lost when the Connector for WebSphere rewrites the file with the encrypted password. You may want to save a copy of the NetPointWASRegistry.properties.Restart the WAS Server.
Ensure that the WebSphere Application server and Portal Server is stopped.
Make a back-up copy of the following file:
WPS_install_dir/config/wpconfig.properties file
Where WPS_install_dir is the directory where WebSphere Portal Server is installed.
Edit the wpconfig.properties file and add the following:
PortalAdminId (Example: PortalAdminId=DN of wpsadministrator) PortalAdminIdShort (Example: PortalAdminIdShort=wpsadministrator) PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword) WasUserid (Example: WasUserid=wasadministrator) WasPassword (Example: WasPassword=wasadminpassword) PortalAdminGroupId (Example: PortalAdminGroupId=DN of PortalAdminGroupId) PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort=PortalAdminGroupId)
Restart the WebSphere Application server.
Optional: Turn PUMA traces on in Portal, which can be done by entering the following in the log.properties file.
For example:
WPS_install_dir\shared\app\config\log.properties
traceString=com.ibm.wps.services.puma.*=all=enabled:com.ibm.wps.puma.*=all=enabled:com.ibm.wps.command.puma.*=all=enable
Backup the following file:
WPS_install_dir/shared/app/wmm/wmm.xml file
Edit the file to make the changes for CMR configuration as follows (and the lookaside flag should be set to "false").
Note that the file named customRepositoryAttributes.xml is a dummy file and is not part of the WebSphere or Oracle Access Manager configuration.
<supportedMemberTypes> <supportedMemberType name="Person" rdnAttrTypes="uid" defaultParentMember="o=company,c=us" defaultProfileRepository="CNR"/> <!-- o=company,c=us is Root DN. please enter the DN in your environment. --> <supportedMemberType name="Group" rdnAttrTypes="cn" defaultParentMember="o=company,c=us" defaultProfileRepository="CNR"/> <!-- Name of the CMR information tag --> </supportedMemberTypes> <profileRepository name="NetpointCustomRepository" UUID="CNR" description="This is Oracle WMM custom MemberRepository implementation." vendor="Oracle" adapterClassName="com.oblix.registry.NetPointMemberRepositoryImpl_v5" specVersion="1.0" adapterVersion="2.0" configurationFile="customRepositoryAttributes.xml" wmmGenerateExtId="false" supportGetPersonByAccountName="false" supportDynamicAttributes="false" profileRepositoryForGroups="CNR" enableTrace="true " PumaService.properties="WPSInstallDir/shared/app/config/services/PumaService.properties" NetPointWASRegistry.properties="NetpointWASConnInstallDir\oblix\config\NetPointWASRegistry.properties"> <!-- 1. com.oblix.registry.NetPointMemberRepositoryImpl_v5 is name of the CMR implementtion class 2. Mention path of the PUMA service against PumaService.properties paramter. 3. NetPointWASRegistry.properties - Path of the Oracle Access Manager WAS registry configuration file. For Unix this path should be mentioned as "NetpointWASConnInstallDir/oblix/config/NetPointWASRegistry.properties 4. CustomRepositoryAttributes.xml is a dummy file. --> <readMemberType> <memberType name="Person" /> <memberType name="Group" /> <!-- Only read access to portal is provided by COREid Connector CMR--> </readMemberType> <createMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't create in the sample --> </createMemberType> <updateMemberType> <!-- <memberType name="Person" /> <memberType name="Group" / > --> <!-- Commented out - can't update in the sample --> </updateMemberType> <deleteMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't delete in the sample --> </deleteMemberType> <renameMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't rename in the sample --> </renameMemberType> <moveMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't move in the sample --> </moveMemberType> <nodeMaps> <nodeMap node="o=company,c=us" pluginNode="o=company,c=us" /> <!-- Root DN configured in your environment --> </nodeMaps> </profileRepository>
In the PumaService.properties file, ensure that the following filters are correct for your environment and edit the values if needed.
For example:
WPS_install_dir\shared\app\config\services\PumaService.properties
user.base.attributes=cn,uid,cn,logonId,logonPasswordVerify,logonPassword ...
group.base.attributes=cn,uniqueOwnerIdentifier,membergroups,groupmembers,memberGroupName,memberGroupType,distinguishedName...
Ensure that the user.minimum.attributes values include all attributes for the user that the CMR will retrieve from the Oracle Access Manager back-end application and send to the WAS portal server. For example:
user.minimum.attributes=cn,genUserid,cn,givenName,sn,mail...
Ensure that you specify the uniquemember attribute to retrieve group members:
group.minimum.attributes=cn,uniquemember...
In the PumaService.properties file, ensure that all user.minimum.attributes have the correct attribute access control for the Administrator and all are in one of the Identity System panels, as described in the Oracle Access Manager Identity and Common Administration Guide.
From the Identity System Console menu click User Manager Configuration, click the Configure Tab, click the tab link, click View Object Profile, then click Configure Panels.
Configure WebSphere Portal security by executing the following command.
Note that some WPSConfig steps may overwrite all of the files that you modified prior to this step, so it is necessary to back up all of these files.
WPS_install_dir/config/WPSConfig.bat action-secure-portal-ldap
Stop WebSphere Portal Server.
Make sure all the configuration file changes done before running WPSConfig.bat are in place.
Restart WebSphere Portal server.
Make sure the systemcred.dn is valid in the following file:
WPS_install_dir\shared\app\config\services\VaultService.properties file
For example:
systemcred.dn=cn=PortalAdmin,o=company,c=us
Note:
This is always the fully qualified unquiet of wpsadmin.Configure WebSphere Portal credentials by executing the following command
Access http://host:port/wps/portal.
WPS_install_dir/config/WPSConfig.bat action-create-deployment-credentials
where host is the fully qualified server name and port is the port number configured for the Portal Server.
Log in to the Portal as the Oracle Access Manager admin user.
Login should be successful and the Admin user should able to search for users and groups in the Oracle Access Manager repository.
Integrating the WebSphere Portal v5.1 for Oracle Access Manager involves a series of installation and configuration tasks.
To integrate the WebSphere Portal v5.1 with Oracle Access Manager
Complete the tasks in "Preparing to Install the Connector":
Install the WebSphere Application Server with appropriate Fix Pack as described in the WebSphere documentation to correct the following issues.
For example:
Issue: Access permission is not working for any user dn containing intermediate spaces after the comma separators, as in the following: cn=PortalUser, o=company, c=us.
Consult IBM Fix PQ93461 for details about this Portal User access permission problem.
Action: This IBM fix pack needs to be applied. Please verify the Portal Server History Log to ensure that all required fixes have been installed. Refer to the Portal Infocenter documentation for additional details.
Install the WebSphere Portal with WebSphere Application Server security disabled.
Note:
Both the Global and Java 2 security should be disabled while installing the Portal Server.See the IBM WebSphere Portal Infocenter documentation for details on installation.
Apply Fixes PQ99439 and PK02868_510. This is required for custom user registry configuration of WebSphere Portal 5.1. (If these fixes are not applied, task enable-security-wmmur-custom will fail.)
Apply the latest available "Member Manager cumulative fix for WebSphere Portal version 5.1." This includes a fix for the group membership feature. This cumulative fix is located at the following Web site:
http://www-1.ibm.com/support/docview.wss?rs=0&uid=swg24009153
Install and configure Oracle Access Manager, as covered in "Preparing to Install the Connector".
Install the Connector for WebSphere and configure the NetpointWASRegistry and TAI components, as described in "Installing the Connector for WebSphere".
Complete Connector setup and testing, as covered in "Completing Connector Setup".
In the WebSphere Administration Console, change security to custom registry. This specifies the NetPointWASRegistry, which establishes a connection between the WAS and Oracle Access Manager. The WAS uses the NetPointWASRegistry to authenticate and authorize portal users through Access System security policies.
Ensure that the following Admin credentials are set in clear text in the NetPointWASRegistry.properties file:
OB_AdminUserName=admin OB_AdminUserCreds=password
Where the OB_AdminUserName value is the user ID of the Portal Server administrator who is a Master Identity Administrator or Oracle Access Manager Administrator. This is required for the CMR. The Admin credentials should be set in clear text. The NetPointWASRegistry reads the password, encrypts it, and rewrites the properties file with the encrypted password. The encryptor can be executed by running the registryTester program, as well as from WebSphere. To assist you with adding these parameters, see the NetPointWASRegistryProperties.sample file, which includes comments. For additional details, consult, "NetPointWASRegistry.properties".
Note:
NetPointWASRegistry.properties file formatting is lost when the Connector for WebSphere rewrites the file with the encrypted password. Therefore, you may want to save a copy of the NetPointWASRegistry.properties.Restart the WAS Server.
Ensure that both the WebSphere Application server and Portal Server are stopped.
Make a back-up copy of the following file:
WPS_install_dir/config/wpconfig.properties
Where WPS_install_dir is the directory where WebSphere Portal Server is installed.
Edit the wpconfig.properties file and add the following:
PortalAdminId (Example: PortalAdminId= DN of wpsadministrator ) PortalAdminIdShort (Example: PortalAdminId= wpsadministrator ) PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword ) WasUserid (Example: WasUserid=wasadministrator ) WasPassword (Example: WasPassword=wasadminpassword ) PortalAdminGroupId (Example: PortalAdminGroupId= DN of PortalAdminGroupId ) PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort= PortalAdminGroupId ) LTPAPassword (Example: LTPAPassword= Password configured for LTPA in the AppServer Configuration) WmmSystemId (Example: WmmSystemId= Set this value to same as that of PortalAdminIdShort) WmmSystemIdPassword (Example: WmmSystemIdPassword= Set this value to same as that of PortalAdminPwd) LDAPSuffix (Example: LDAPSuffix=o=company,c=us LDAP suffix of Oracle Access Manager installation) LDAPUserSuffix (Example: LDAPUserSuffix=ou=users Keep this blank if user-nodes are directly under LDAPSuffix) LDAPGroupSuffix (Example: LDAPGroupSuffix=ou=groups Keep this blank if group-nodes are directly under LDAPSuffix) LdapUserPrefix (Example: LdapUserPrefix=cn ) LdapGroupPrefix (Example: LdapGroupPrefix=cn ) PortalAdminId (Example: PortalAdminId= DN of wpsadministrator ) PortalAdminIdShort (Example: PortalAdminId= wpsadministrator ) PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword ) WasUserid (Example: WasUserid=wasadministrator ) WasPassword (Example: WasPassword=wasadminpassword ) PortalAdminGroupId (Example: PortalAdminGroupId= DN of PortalAdminGroupId ) PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort= PortalAdminGroupId ) LTPAPassword (Example: LTPAPassword= Password configured for LTPA in the AppServer Configuration) WmmSystemId (Example: WmmSystemId= Set this value to same as that of PortalAdminIdShort) WmmSystemIdPassword (Example: WmmSystemIdPassword= Set this value to same as that of PortalAdminPwd) LDAPSuffix (Example: LDAPSuffix=o=company,c=us LDAP suffix of Oracle Access Manager installation) LDAPUserSuffix (Example: LDAPUserSuffix=ou=users Keep this blank if user-nodes are directly under LDAPSuffix) LDAPGroupSuffix (Example: LDAPGroupSuffix=ou=groups Keep this blank if group-nodes are directly under LDAPSuffix) LdapUserPrefix (Example: LdapUserPrefix=cn ) LdapGroupPrefix (Example: LdapGroupPrefix=cn )
Restart the WebSphere Application server.
Optional: Turn on PUMA traces in Portal, which can be done by entering the following in the log.properties file, which typical resides at
WPS_install_dir\shared\app\config\log.properties
traceString=com.ibm.wps.services.puma.*=all=enabled:com.ibm.wps.puma.*=all=enabled:com.ibm.wps.command.puma.*=all=enable
Back up the following files:
WPS_install_dir/wmm/wmm.xml
WPS_install_dir/wmm/wmm_DB.xml
Make a copy of wmm.xml and save it under the name wmm_custom.xml in the same folder as wmm.xml (WPS_install_dir/wmm/wmm_custom.xml).
Edit wmm_custom.xml, changing your CMR configuration as follows, and verify that the lookaside flag is set to false.
<supportedMemberTypes> <supportedMemberType name="Person" rdnAttrTypes="uid" defaultParentMember="o=company,c=us" defaultProfileRepository="CNR"/> <!-- o=company,c=us is Root DN. please enter the DN in your environment. --> <supportedMemberType name="Group" rdnAttrTypes="cn" defaultParentMember="o=company,c=us" defaultProfileRepository="CNR"/> <!-- Name of the CMR information tag --> </supportedMemberTypes> <profileRepository name="NetpointCustomRepository" UUID="CNR" description="This is Oracle WMM custom MemberRepository implementation." vendor="Oracle" adapterClassName="com.oblix.registry.NetPointMemberRepositoryImpl_v51" specVersion="1.0" adapterVersion="2.0" configurationFile="customRepositoryAttributes.xml" wmmGenerateExtId="false" supportGetPersonByAccountName="false" supportDynamicAttributes="false" profileRepositoryForGroups="CNR" enableTrace="true " PumaService.properties="WPSInstallDir/shared/app/config/services/PumaService.properties" NetPointWASRegistry.properties="NetpointWASConnInstallDir\oblix\config\NetPointWASRegistry.properties"> <!-- 1. com.oblix.registry.NetPointMemberRepositoryImpl_v51 is name of the CMR implementation class 2. Mention path of the PUMA service against PumaService.properties paramter. 3. NetPointWASRegistry.properties - Path of the Oracle Access Manager WAS registry configuration file. For Unix this path should be mentioned as "NetpointWASConnInstallDir/oblix/config/NetPointWASRegistry.properties 4. CustomRepositoryAttributes.xml is a dummy file. --> <readMemberType> <memberType name="Person" /> <memberType name="Group" /> <!-- Only read access to portal is provided by COREid Connector CMR--> </readMemberType> <createMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't create in the sample --> </createMemberType> <updateMemberType> <!-- <memberType name="Person" /> <memberType name="Group" / > --> <!-- Commented out - can't update in the sample --> </updateMemberType> <deleteMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't delete in the sample --> </deleteMemberType> <renameMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't rename in the sample --> </renameMemberType> <moveMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't move in the sample --> </moveMemberType> <nodeMaps> <nodeMap node="o=company,c=us" pluginNode="o=company,c=us" /> <!-- Root DN configured in your environment --> </nodeMaps> </profileRepository>
Overwrite the following files with new contents of wmm_custom.xml:
WPS_install_dir/wmm/wmm.xml
WPS_install_dir/wmm/wmm_DB.xml
Ensure that the following filters are correct for your environment in the following file:
WPS_install_dir\shared\app\config\services\PumaService.properties
In this file, ensure that the user.minimum.attributes include all attributes for the user that the CMR will retrieve from Oracle Access Manager and send to the WAS portal server.In the required attributes list in user.base.attributes, enter all attributes that are required for searching in the WAS portal server for users with these attribute values.Make sure that group.minimum.attributes has assigned uniqueMember and class attribute configured for Group object class. (In the following sample file it is "cn").The user.password.attribute should be set to name of the password attribute.Ensure that directory is set to CUSTOM.Edit the values, as needed.
#SAMPLE PumaService.properties file. Please make changes according to your environment #In the following sample file. User object classAttribute is uid and Group object class attribute is cn. #Please set these values according to your environment. user.fbadefault.filter=uid user.template.attribute=uid user.password.attribute=userPassword user.minimum.attributes=uid,cn user.base.attributes=uid,cn,givenName,sn,preferredLanguage user.sync.remove.attributes=passwordCreation,RDN,lastSession,selfAddress,packageSuppression,createdTimestamp,policyAccountId,registrationUpdate,uniqueUserIdentifier,memberId,ancestors,addressId,truncatedUniqueIdentifier,profileType,registration,primary,approvalState,lastOrder,publishPhone2,publishPhone1,salt,addressBookId,uniqueParentIdentifier,parentMemberId,registrationCancel,passwordExpired,previousLastSession,displayName,addressType,shortName,preferredLanguageId,userId,timeout,registerType,uniqueIdentifier,passwordInvalid,nickName,type,membergroups,income,age,organizationUnitId,demographicField6,children,household,status,passwordRetries,uniqueNumericIdentifier,cn group.fbadefault.filter=cn group.template.attribute=cn group.minimum.attributes=cn,uniqueMember group.base.attributes=cn,uniqueMember group.sync.remove.attributes=uniqueOwnerIdentifier,membergroups,groupmembers,memberGroupName,memberGroupType,distinguishedName,cn,uniqueNumericIdentifier,uniqueMemberIdentifier directory=CUSTOM ejbName=ejb/MemberServiceHome
Ensure that all user.minimum.attributes have the correct attribute access controls for the Administrator.
See Oracle Access Manager Identity and Common Administration Guide for details.
Also ensure that all user.minimum.attributes are in one of the Identity System panels, as described in the Oracle Access Manager Identity and Common Administration Guide.
To access these panels, from the Identity System Console, click User Manager Configuration, click Tabs, click the link for the tab, click View Object Profile, then click Configure Panels.
Modify the file WPS_install_dir/wmm/wmmWASAdmin.xml as follows:
<?xml version="1.0" encoding="UTF-8"?> <wmmWASAdmins> <admin logonId="PortalAdmin" logonPassword="oblixoblix" uniqueUserId="cn=Portal Admin,o=company,c=us"/> </wmmWASAdmins>
logonId, logonPassword and uniqueUserId correspond to the new values of PortalAdminIdShort, PortalAdminId, and PortalAdminPwd respectively in wpconfig.properties.
Modify the WPS_install_dir/wmm/wmmur.xml file.
Set the value of wmmnode to your LDAPRoot as follows:
<node wmmnode="o=company,c=us"/>
Modify WPS_install_dir/wmm/wmmAttributes.xml so that it contains only supported attributes.
The wmmAttributes.xml file contains definitions of all the supported attributes. Each attribute definition might have two properties named applicableMemberTypes and requiredMemberTypes. Values of these properties should be supported member types. For example, if wmm_custom.xml has only two supportedMemberTypes (Person and Group), then other types such as organizationalUnit or organization should not be applicableMemberTypes or requiredMemberTypes for any of the attributes in wmmAttributes.xml.
Modify WPS_install_dir/shared/app/config/services/VaultService.properties.
Set the value of systemcred.dn to the DN of wpsadministrator.
Example:
systemcred.dn=cn=Portal Admin,o=company,c=us
Backup all configuration files, stop the portal server, then configure WebSphere Portal security by executing the following command:
WPS_install_dir/config/WPSConfig.bat enable-security-wmmur-custom
Verify that all of the configuration files are in place.
You can compare the values with the backup copies that you created in the previous step.
The contents of wmm.xml should match the contents of wmm_custom.xml.
Restart the portal server.
Access the following Web page:
http://host:port/wps/portal
where host is the fully qualified server name and port is the port number configured for the Portal Server.
Log in to the Portal as the Oracle Access Manager admin user. The Login should succeed, and Admin user should able to search for other Oracle Access Manager Repository users and groups.
Integrating the WebSphere Portal v5.1 for Oracle Access Manager involves a series of installation and configuration tasks.
To integrate the WebSphere Portal v6.0 with Oracle Access Manager
Complete the tasks in "Preparing to Install the Connector":
Install the WebSphere Application Server.
Install the WebSphere Portal with WebSphere Application Server security disabled.
Note:
Both the Global and Java 2 security should be disabled while installing the Portal Server.See the IBM WebSphere Portal Infocenter documentation for details on installation.
Install and configure Oracle Access Manager, as covered in "Preparing to Install the Connector".
Install the Connector for WebSphere and configure the NetpointWASRegistry and TAI components, as described in "Installing the Connector for WebSphere".
Complete Connector setup and testing, as covered in "Completing Connector Setup".
In the WebSphere Administration Console, change security to custom registry. This specifies the NetPointWASRegistry, which establishes a connection between the WAS and Oracle Access Manager. The WAS uses the NetPointWASRegistry to authenticate and authorize portal users through Access System security policies.
Ensure that the following Admin credentials are set in clear text in the NetPointWASRegistry.properties file:
OB_AdminUserName=admin OB_AdminUserCreds=password
Where the OB_AdminUserName value is the user ID of the Portal Server administrator who is a Master Identity Administrator or Oracle Access Manager Administrator. This is required for the CMR. The Admin credentials should be set in clear text. The NetPointWASRegistry reads the password, encrypts it, and rewrites the properties file with the encrypted password. The encryptor can be executed by running the registryTester program, as well as from WebSphere. To assist you with adding these parameters, see the NetPointWASRegistryProperties.sample file, which includes comments. For additional details, consult, "NetPointWASRegistry.properties".
Note:
NetPointWASRegistry.properties file formatting is lost when the Connector for WebSphere rewrites the file with the encrypted password. Therefore, you may want to save a copy of the NetPointWASRegistry.properties.Restart the WAS Server.
Ensure that both the WebSphere Application server and Portal Server are stopped.
Make a back-up copy of the following file:
WPS_install_dir/config/wpconfig.properties
Where WPS_install_dir is the directory where WebSphere Portal Server is installed.
Edit the wpconfig.properties file and add the following:
PortalAdminId (Example: PortalAdminId= DN of wpsadministrator) PortalAdminIdShort (Example: PortalAdminId= wpsadministrator) PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword) WasUserid (Example: WasUserid=wasadministrator) WasPassword (Example: WasPassword=wasadminpassword) PortalAdminGroupId (Example: PortalAdminGroupId= DN of PortalAdminGroupId) PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort= PortalAdminGroupId) LTPAPassword (Example: LTPAPassword= Password configured for LTPA in the AppServer Configuration) WmmSystemId (Example: WmmSystemId= Set this value to same as that of PortalAdminIdShort) WmmSystemIdPassword (Example: WmmSystemIdPassword= Set this value to same as that of PortalAdminPwd) LDAPSuffix (Example: LDAPSuffix=o=company,c=us LDAP suffix of Oracle Access Manager installation) LDAPUserSuffix (Example: LDAPUserSuffix=ou=users Keep this blank if user-nodes are directly under LDAPSuffix) LDAPGroupSuffix (Example: LDAPGroupSuffix=ou=groups Keep this blank if group-nodes are directly under LDAPSuffix) LdapUserPrefix (Example: LdapUserPrefix=cn) LdapGroupPrefix (Example: LdapGroupPrefix=cn)
PortalAdminId (Example: PortalAdminId= DN of wpsadministrator ) PortalAdminIdShort (Example: PortalAdminId= wpsadministrator ) PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword ) WasUserid (Example: WasUserid=wasadministrator ) WasPassword (Example: WasPassword=wasadminpassword ) PortalAdminGroupId (Example: PortalAdminGroupId= DN of PortalAdminGroupId ) PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort= PortalAdminGroupId ) LTPAPassword (Example: LTPAPassword= Password configured for LTPA in the AppServer Configuration) WmmSystemId (Example: WmmSystemId= Set this value to same as that of PortalAdminIdShort) WmmSystemIdPassword (Example: WmmSystemIdPassword= Set this value to same as that of PortalAdminPwd) LDAPSuffix (Example: LDAPSuffix=o=company,c=us LDAP suffix of Oracle Access Manager installation) LDAPUserSuffix (Example: LDAPUserSuffix=ou=users Keep this blank if user-nodes are directly under LDAPSuffix) LDAPGroupSuffix (Example: LDAPGroupSuffix=ou=groups Keep this blank if group-nodes are directly under LDAPSuffix) LdapUserPrefix (Example: LdapUserPrefix=cn ) LdapGroupPrefix (Example: LdapGroupPrefix=cn ) PortalAdminId (Example: PortalAdminId= DN of wpsadministrator ) PortalAdminIdShort (Example: PortalAdminId= wpsadministrator ) PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword ) WasUserid (Example: WasUserid=wasadministrator ) WasPassword (Example: WasPassword=wasadminpassword ) PortalAdminGroupId (Example: PortalAdminGroupId= DN of PortalAdminGroupId ) PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort= PortalAdminGroupId ) LTPAPassword (Example: LTPAPassword= Password configured for LTPA in the AppServer Configuration) WmmSystemId (Example: WmmSystemId= Set this value to same as that of PortalAdminIdShort) WmmSystemIdPassword (Example: WmmSystemIdPassword= Set this value to same as that of PortalAdminPwd) LDAPSuffix (Example: LDAPSuffix=o=company,c=us LDAP suffix of Oracle Access Manager installation) LDAPUserSuffix (Example: LDAPUserSuffix=ou=users Keep this blank if user-nodes are directly under LDAPSuffix) LDAPGroupSuffix (Example: LDAPGroupSuffix=ou=groups Keep this blank if group-nodes are directly under LDAPSuffix) LdapUserPrefix (Example: LdapUserPrefix=cn ) LdapGroupPrefix (Example: LdapGroupPrefix=cn )
Note that the script may fail unless you set the following parameters:
WpsContentAdministrators (Example: WpsContentAdministrators = DN of Content Administrator group) WpsDocReviewer (Example: WpsDocReviewer = DN of Document Reviewer group)
Restart the WebSphere Application server.
Optional: Turn on PUMA traces in Portal, which can be done by entering the following in the log.properties file, which typical resides at
WPS_install_dir\shared\app\config\log.properties
traceString=com.ibm.wps.services.puma.*=all=enabled:com.ibm.wps.puma.*=all=enabled:com.ibm.wps.command.puma.*=all=enable
Back up the following files:
WPS_install_dir/wmm/wmm.xml
WPS_install_dir/wmm/wmm_DB.xml
Make a copy of wmm.xml and save it under the name wmm_custom.xml in the same folder as wmm.xml (WPS_install_dir/wmm/wmm_custom.xml).
Edit wmm_custom.xml, changing your CMR configuration as follows, and verify that the lookaside flag is set to false.
<supportedMemberTypes> <supportedMemberType name="Person" rdnAttrTypes="uid" defaultParentMember="o=company,c=us" defaultProfileRepository="CNR"/> <!-- o=company,c=us is Root DN. please enter the DN in your environment. --> <supportedMemberType name="Group" rdnAttrTypes="cn" defaultParentMember="o=company,c=us" defaultProfileRepository="CNR"/> <!-- Name of the CMR information tag --> </supportedMemberTypes> <profileRepository name="NetpointCustomRepository" UUID="CNR" description="This is Oracle WMM custom MemberRepository implementation." vendor="Oracle" adapterClassName="com.oblix.registry.NetPointMemberRepositoryImpl_v51" specVersion="1.0" adapterVersion="2.0" configurationFile="customRepositoryAttributes.xml" wmmGenerateExtId="false" supportGetPersonByAccountName="false" supportDynamicAttributes="false" profileRepositoryForGroups="CNR" enableTrace="true " PumaService.properties="WPSInstallDir/config/properties/PumaService.properties" NetPointWASRegistry.properties="NetpointWASConnInstallDir\oblix\config\NetPointWASRegistry.properties"> <!-- 1. com.oblix.registry.NetPointMemberRepositoryImpl_v51 is name of the CMR implementation class 2. Mention path of the PUMA service against PumaService.properties paramter. 3. NetPointWASRegistry.properties - Path of the Oracle Access Manager WAS registry configuration file. For Unix this path should be mentioned as "NetpointWASConnInstallDir/oblix/config/NetPointWASRegistry.properties 4. CustomRepositoryAttributes.xml is a dummy file. --> <readMemberType> <memberType name="Person" /> <memberType name="Group" /> <!-- Only read access to portal is provided by COREid Connector CMR--> </readMemberType> <createMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't create in the sample --> </createMemberType> <updateMemberType> <!-- <memberType name="Person" /> <memberType name="Group" / > --> <!-- Commented out - can't update in the sample --> </updateMemberType> <deleteMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't delete in the sample --> </deleteMemberType> <renameMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't rename in the sample --> </renameMemberType> <moveMemberType> <!-- <memberType name="Person" /> <memberType name="Group" /> --> <!-- Commented out - can't move in the sample --> </moveMemberType> <nodeMaps> <nodeMap node="o=company,c=us" pluginNode="o=company,c=us" /> <!-- Root DN configured in your environment --> </nodeMaps> </profileRepository>
Overwrite the following files with new contents of wmm_custom.xml:
WPS_install_dir/wmm/wmm.xml
WPS_install_dir/wmm/wmm_DB.xml
Ensure that the following filters are correct for your environment in the following file:
WPS_install_dir\config\properties\PumaService.properties
In this file, ensure that the user.minimum.attributes include all attributes for the user that the CMR will retrieve from Oracle Access Manager and send to the WAS portal server.In the required attributes list in user.base.attributes, enter all attributes that are required for searching in the WAS portal server for users with these attribute values.Make sure that group.minimum.attributes has assigned uniqueMember and class attribute configured for Group object class. (In the following sample file it is "cn").The user.password.attribute should be set to name of the password attribute.Ensure that directory is set to CUSTOM.Edit the values, as needed.
#SAMPLE PumaService.properties file. Please make changes according to your environment #In the following sample file. User object classAttribute is uid and Group object class attribute is cn. #Please set these values according to your environment. user.fbadefault.filter=uid user.template.attribute=uid user.password.attribute=userPassword user.minimum.attributes=uid,cn user.base.attributes=uid,cn,givenName,sn,preferredLanguage user.sync.remove.attributes=passwordCreation,RDN,lastSession,selfAddress,packageSuppression,createdTimestamp,policyAccountId,registrationUpdate,uniqueUserIdentifier,memberId,ancestors,addressId,truncatedUniqueIdentifier,profileType,registration,primary,approvalState,lastOrder,publishPhone2,publishPhone1,salt,addressBookId,uniqueParentIdentifier,parentMemberId,registrationCancel,passwordExpired,previousLastSession,displayName,addressType,shortName,preferredLanguageId,userId,timeout,registerType,uniqueIdentifier,passwordInvalid,nickName,type,membergroups,income,age,organizationUnitId,demographicField6,children,household,status,passwordRetries,uniqueNumericIdentifier,cn group.fbadefault.filter=cn group.template.attribute=cn group.minimum.attributes=cn,uniqueMember group.base.attributes=cn,uniqueMember group.sync.remove.attributes=uniqueOwnerIdentifier,membergroups,groupmembers,memberGroupName,memberGroupType,distinguishedName,cn,uniqueNumericIdentifier,uniqueMemberIdentifier directory=CUSTOM ejbName=ejb/MemberServiceHome
Ensure that all user.minimum.attributes have the correct attribute access controls for the Administrator.
See Oracle Access Manager Identity and Common Administration Guide for details.
Also ensure that all user.minimum.attributes are in one of the Identity System panels, as described in the Oracle Access Manager Identity and Common Administration Guide.
To access these panels, from the Identity System Console, click User Manager Configuration, click Tabs, click the link for the tab, click View Object Profile, then click Configure Panels.
Modify the file WPS_install_dir/wmm/wmmWASAdmin.xml as follows:
<?xml version="1.0" encoding="UTF-8"?> <wmmWASAdmins> <admin logonId="PortalAdmin" logonPassword="oblixoblix" uniqueUserId="cn=Portal Admin,o=company,c=us"/> </wmmWASAdmins>
Where logonId, logonPassword and uniqueUserId correspond to the new values of PortalAdminIdShort, PortalAdminPwd, and PortalAdminId respectively in wpconfig.properties.
Modify the WPS_install_dir/wmm/wmmur.xml file.
Set the value of wmmnode to your LDAPRoot as follows:
<node wmmnode="o=company,c=us"/>
Modify WPS_install_dir/wmm/wmmAttributes.xml so that it contains only supported attributes.
The wmmAttributes.xml file contains definitions of all the supported attributes. Each attribute definition might have two properties named applicableMemberTypes and requiredMemberTypes. Values of these properties should be supported member types. For example, if wmm_custom.xml has only two supportedMemberTypes (Person and Group), then other types such as organizationalUnit or organization should not be applicableMemberTypes or requiredMemberTypes for any of the attributes in wmmAttributes.xml.
Modify WPS_install_dir/config/properties/VaultService.properties.
Set the value of systemcred.dn to the DN of wpsadministrator.
Example:
vault.default-release.class=com.ibm.wps.services.credentialvault.DefaultVault vault.default-release.config=defaultvault vault.default-release.domain=rel vault.default-release.manageresources=true vault.default-release.readonly=false systemcred.dn=cn=Portal Admin,o=company,c=us
Back up all configuration files, stop the portal server, then configure WebSphere Portal security by executing the following command:
WPS_install_dir/config/WPSConfig.bat enable-security-wmmur-custom
Verify that all of the configuration files are in place.
You can compare the values with the backup copies that you created in the previous step.
The contents of wmm.xml should match the contents of wmm_custom.xml.
Restart the portal server.
Access the following Web page:
http://host:port/wps/portal
where host is the fully qualified server name and port is the port number configured for the Portal Server.
Log in to the Portal as the Oracle Access Manager admin user. The Login should succeed, and Admin user should able to search for other Oracle Access Manager Repository users and groups.
Portal Administrators can use the Identity System to perform user and group management tasks such as adding or deleting users and groups, modifying user profiles and attributes.
To use the Identity System user and group management functionality, ensure that you do not create users and groups in the WebSphere Portal. Instead, create and modify users and groups in the Identity System.
You can add and delete static groups and user membership in groups through the Identity System. The information that you update in the Identity System is immediately reflected in the WebSphere Portal.
Note:
To recognize group membership, the Identity System requires the dynamic group to be expanded.After you create users and groups in the Identity System, you can search for them in the WebSphere Portal.
See the Oracle Access Manager Identity and Common Administration Guide for more information on managing users and groups.
When users modify their profile through the Identity System, the modifications are immediately visible in the WebSphere Portal. This ensures that the most current user information is used when portal developers personalize user pages.
You can map additional attributes to a use's profile if necessary. See the WebSphere Portal documentation for information on mapping attributes.
Because the portal uses Access System SSO, users are subject to the Oracle Access Manager password policies during authentication.
Important:
To implement the password management feature, turn off the portal's password management functionality.The Oracle Access Manager password management functionality includes defining password policies, resetting passwords, expiration notification, and challenge phrases for lost passwords.
See the Oracle Access Manager Identity and Common Administration Guide for more information on password policies.
Portal administrators use the portal's access control functionality to grant access to portlets. From the WebSphere Portal, administrators can search for Oracle Access Manager-managed users and groups to whom they want to grant portal administration privileges as well as portlet access control.
Configuring SSO between the Access System and the WebSphere portal enables the WebSphere portal to utilize the ObSSOCookie and enable Connector for WebSphere to authenticate Oracle Access Manager users.
Configuring SSO logout for the WebSphere Portal Server ensures that when a user logs out of a Access System-protected WebSphere resource, both the LTPA token and the ObSSOCookie are killed. The user will not be able to access any other WebSphere resource or other Access System-protected resources without authenticating again.
If you have configured the TAI for single sign-on between Oracle Access Manager and WebSphere, you must configure single sign-on logout for the WebSphere Portal Server.
If you have not configured the TAI for single sign-on, users can use the portal's logout button to log out of all Access System-protected resources.
To configure single sign-on for the WebSphere Portal v5 and v6
Install the WebGate plug-in for the Web server that you selected when you installed the WebSphere Portal.
In the Policy Manager, define the URL that you want to protect.
A WebGate prompts for authentication when users attempt to log in to this URL. Be sure to protect / if you want the WebGate to prompt for authentication when the user gets to the root of the WebSphere Portal. You can also add other authorization rules, if needed.
Note:
To protect resources, Oracle recommends that you use a form-based authentication scheme. However, if you use the basic authentication scheme, set the Challenge Redirect field to another WebGate to ensure that the ObSSOCookie gets set. See the Oracle Access Manager Access System Administration Guide for more information on authentication schemes.To configure single sign-on logout for WebSphere Portal v5 and v6
Create an Access System policy with a Form Over LDAP type of authentication scheme to protect the portal URL, as described in the Oracle Access Manager Access System Administration Guide.
Create a custom logout page using HTML, JSP, or CGI protocol.
The default logout page for Oracle Access Manager, logout.html, is located in:
WebGate_install_dir\access\oblix\apps\common\bin
Where WebGate_install_dir is the directory where the WebGate is installed.
Save the logout page in the document root of the Web server on which the WebGate that protects WebSphere is installed.
For example:
http://foobar/myportal/logout.html
Note:
Ensure that the name of the logout page contains the string "logout".Protect the logout page with an Access System policy, as described in the Oracle Access Manager Access System Administration Guide.
Locate and open the following file:
For WebSphere Portal version 5:
WPS_install_dir\shared\app\config\services\ConfigServices.propertiesFor WebSphere Portal version 6:
WPS_install_dir\config\properties\ConfigServices.propertiesWhere WPS_install_dir is the directory where WebSphere Portal Server is installed.
Add the following two parameters in ConfigServices.properties file:
redirect.logout = true
redirect.logout.url = The path to the logout page
For example:
http://foobar/myportal/logout.html
For WebSphere Portal v5, back up the properties files in WPS_Install_Dir/config/properties/
For Websphere Portal v6, back up the properties files in the following directory:
WPS_Install_Dir/config/properties/
Ensure that the Application Server and Portal Server are not running.
On Windows, run the following command:
WPS_Install_Dir\config\WPSconfig.bat update-properties
On UNIX, run the following command:
WPS_Install_Dir/config/WPSconfig.sh update-properties
After successfully completing the commands, restore the properties files from backup.
Restart the WebSphere Portal Server and Application Server.
The following configuration files are used when integrating Connector for WebSphere with WAS:
Table 11-1 describes the parameters of NetPointWASRegistry.properties file located in CWS_install_dir /oblix/config. This file contains data that was specified during NetPointWASRegistry installation, as well as some default parameter values for logging. For example:
# Logging level (none, info or debug); OB_LogLevel=debug OB_LogFileName=C:/CWS_install_dir/log
The Oracle Access Manager Connector for WebSphere caches data that it receives from the Access or Identity Server. For subsequent requests from WebSphere servers, user and group data is retrieved from the connector cache. The caches are updated on a scheduled basis. Each user, group, or user profile attribute entry in the connector cache is associated with a Time To Live (TTL) parameter that is defined in the NetPointWASRegistry.properties file. When a request is issued after the timeout limit is reached, the cache miss handler is invoked and fresh data is retrieved from the Identity and Access servers. The default timeout for all cache parameters in the NetpointWASRegistry.properties file is 3600 seconds. This value can be set as needed. There is no dynamic cache updating between Identity and Access Servers and the connector. To reflect user, group, or user profile attribute changes immediately, set the cache timeout value to 0. A value of 0 disables the connector cache.
Note:
Webpass to GroupSrvCenter performance has been improved with the addition of configuration options to improve IdentityXML calls in the Identity System. For example, when no nested groups are used and are turned off, you may use a new option so that getGroups will not generate a request for nested groups.Tip:
See also Table 11-1.Table 11-1 Parameters in NetPointWASRegistry.properties
| Parameter Name | Description | Optional/ Mandatory |
|---|---|---|
|
Installation |
. |
. |
|
OB_InstallDir |
The directory where NetPointWASRegistry is installed. |
Mandatory |
|
Logging |
. |
. |
|
OB_LogLevel |
The logging level that is recorded in the log file. Values are none, info, and debug. |
Optional |
|
OB_LogFileName |
The file name for Custom User Registry (NetPointWASRegistry) log messages. Default = CWS_install_dir/log Note: Log messages for the CMR are directed to the WPS_install_dir/log/appserver-out.log file. |
Optional |
|
OB_LogMilliSeconds=true |
The data/time format of log messages in the file specified with OB_LogFileName. When true, log messages are time formatted in milliseconds. Default =true |
Optional |
|
WebPass |
. |
. |
|
OB_WebPassHost |
The WebPass server host machine name. The host name must be fully qualified; for example, OB_WebPassHost=hostname.acme.com. To configure multiple WebPass instances for failover purposes, separate the names with a comma. For example: OB_WebPassHost=foo.domain.com, bar.domain.com Note that the host name corresponds to the port number in the specified order. See the example in the Ob_WebPassPort description in this table. |
Mandatory |
|
OB_WebPassPort |
The port number of the host machine. To configure multiple WebPass instances, separate the port numbers with a comma. For example: OB_WebPassPort=80, 81 Note that the host name corresponds to the port number in the specified order. In this example, the hostname:port number pairing is as follows: foo.domain.com:80 bar.domain.com:81 For failover to work, all other variables such as user name, credentials and webgate protection must be the same. |
Mandatory |
|
OB_WebPassIsProtected |
Values are true and false. If WebPass is protected, set value=true. |
Mandatory |
|
OB_AdminUserName |
The Identity System requires the Admin username and password to make IdentityXML calls to the WebPass. For details about administrator rights, see "Configuring the Identity Server". |
Mandatory |
|
OB_AdminUserCreds |
The Identity System requires the Admin username and password to make IdentityXML calls to the WebPass. Without the password the connector will not work. Note: You need to enter a clear-text password, which the program will encrypt and rewrite to the properties file after the first run. |
Mandatory |
|
Cookie |
. |
. |
|
OB_CookieDomain |
The cookie domain specified in the WebGate installer configuration. Needed if WebPass is protected. For example, .xyz.com |
Mandatory |
|
OB_CookiePath |
The cookie path specified in the WebGate configuration. Needed if WebPass is protected. Default = / |
Mandatory |
|
WebPass SSL |
. |
. |
|
OB_WebPassSSLEnabled |
Specifies whether WebPass needs HTTPS connection. Values are true and false. Default = false |
Mandatory |
|
Login and Search Attributes |
. |
. |
|
OB_UserAttr |
The unique user identification (for example, uid). |
Mandatory |
|
OB_UserSearchAttr |
The DN prefix for users from LDAP (for example, cn). |
Mandatory |
|
OB_GroupSearchAttr |
The DN prefix for groups from LDAP (for example, cn). |
Mandatory |
|
Active Directory Forest |
. |
. |
|
OB_WebPassADDomain |
Optional. The domain of the Admin user. To be used in case of Active Directory Forest with multiple domains. For example, OB_WebPassADDomain=ou=company,dc=qalab,dc=acme,dc=comThe ADDomain must be the same as the default defined in the Identity Server. |
Optional |
|
Records Returned |
. |
. |
|
OB_WebPassXPIRecordsReturned |
Optional. The number of records to return for getUsers or getGroups. This is used only in the WebSphere Portal.Default = return all |
Optional |
|
Authentication |
. |
. |
|
OB_AuthnSchemeResourceTypeName |
Authen |
Mandatory |
|
OB_AuthnSchemeOperation |
LOGIN |
Mandatory |
|
OB_AuthnSchemeResourceName |
/Authen/Basic |
Mandatory |
|
OB_AuthzActionType |
WAS_Registry |
Mandatory |
|
OB_AuthzActionName |
uid |
Mandatory |
|
Cache |
. |
. |
|
OB_AllUserCache_enabled |
Enables caching of all users.Values are true and false. |
Optional |
|
OB_AllUserCache_timeout |
Timeout for cache of list of all users. |
Optional |
|
OB_UserAttributesCache_enabled |
Enables Caching of user attributes.Values are true and false. |
Optional |
|
OB_UserAttributesCache_timeout |
The timeout for the cache of user attributes. Timeout is for the whole cache. |
Optional |
|
OB_UserAttributesCacheElement_timeout |
The timeout for the cached user attributes. The Timeout is per user. |
Optional |
|
OB_GroupAttributesCache_enabled |
Enables Caching of group attributes.Values are true and false. |
Optional |
|
OB_GroupAttributesCache_timeout |
The timeout for the cache of group attributes. Timeout is for the whole cache. |
Optional |
|
OB_GroupAttributesCacheElement_timeout |
The timeout for the cached group attributes. The Timeout is per group. |
Optional |
|
OB_AllGroupCache_enabled |
Enables caching of list of all groups. Values are true and false.Used only for all groups, and mostly used by the Admin Console. |
Optional |
|
OB_AllGroupCache_timeout |
The timeout for cache of the list of all groups. |
Optional |
|
OB_UserGroupsCache_enabled |
Enables caching of list groups of which the user is a member.Values are true and false.Maintains a cache of all the groups a logged in user belongs to. |
Optional |
|
OB_UserGroupsCache_timeout |
The timeout for cache of the list of groups for a user. The timeout is per user. This value should not be very high--if the user's group membership changes the new membership will only take affect at cache timeout. For example, a value of 3600 equates to 1 hour. |
Optional |
|
OB_GroupMembersCache_enabled |
Enables caching of list of groups and list of members in each group.Values are true and false.Stores members for each groups (not a frequently used cache). |
Optional |
|
OB_GroupMembersCache_timeout |
Specifies the timeout for cache of list of groups and the list of members in each group. |
Optional |
|
Keystore |
. |
. |
|
OB_Keystore |
Specifies the keystore file used by the registry when it makes SSL connections to HTTPS WebPass. The keystore contains the requestor's public and private key pairs, X.509 certificate, and certificates for Certificate Authorities trusted to certify responder servers. The keystore is managed using the JDK keytool. For example: CWS_install_dir/oblix/config/jssecacerts |
Optional |
|
OB_KeystorePassword |
Optional. The password for the keystore. |
Optional |
|
Users and Groups |
. |
. |
|
OB_UserTabId |
For future use. Do not change the default.Default = Employees |
Mandatory |
|
OB_GroupTabId |
For future use. Do not change the default.Default = Groups |
Mandatory |
|
Performance |
. |
. |
|
OB_NestedGroupsEnabled |
Values are true and false. The default is true.To improve GroupSrvCenter performance when nested groups are not used, set the value to false.
|
Optional |
|
OB_DynamicGroupsEnabled |
Values are true and false.To improve GroupSrvCenter performance when you are not using dynamic groups, set the value to false. Dynamic groups will not be included in the search. |
Optional |
|
Non-Unique Login ID in Different Domains |
. |
. |
|
OB_DnIsUniqueIdentifier=See also OB_DnIsUniqueIdentifier= in "WebGate.properties". |
Values are true and false. The default is false.Set the value to true to enable the Connector for WebSphere to work in a multi-domain directory server with a non-unique login ID in the different domains. |
Optional |
Table 11-2 describes the parameters of the webgate.properties file. This file is located in CWS_install_dir /oblix/config with a copy in WAS_install_dir \properties.
Table 11-2 Parameters in webgate.properties
| Parameter | Description |
|---|---|
|
OB_InstallDir |
The directory where the NetPointWASRegistry is installed. Default =CWS_install_dir |
|
OB_ISPROXYENABLED |
Not required unless you use a proxy server. The default value is false. If you use a proxy server the value must be changed to true. |
|
OB_hostnames |
Not required unless you use a proxy server. The name of the host machine. This is only used for proxy servers. |
|
Ob_loginID |
Not required. |
|
OB_AuthnSchemeResourceTypeName |
Authen |
|
OB_AuthnSchemeOperation |
LOGIN |
|
OB_AuthnSchemeResourceName |
/Authen/Basic |
|
OB_AuthzActionType |
uid |
|
OB_DnIsUniqueIdentifier |
Not required unless you want to enable the Connector for WebSphere to work in a multi-domain directory server with a non-unique login ID in the different domains. See also, Non-Unique Login ID in Different Domains in "NetPointWASRegistry.properties". |
Table 11-3 describes the parameters of the trustedservers.properties configuration file.
Table 11-3 Parameters in TrustedServers.properties
| Parameter | Description |
|---|---|
|
com.ibm.websphere.security.trustassociation.enabled |
true |
|
com.ibm.websphere.security.trustassociation.types |
webgate |
|
com.ibm.websphere.security.trustassociation.webgate.interceptor |
com.oblix.tai.WebGateTrustAssociationInterceptor |
|
com.ibm.websphere.security.trustassociation.webgate.config |
webgate |
The following implementation is optional to enable the Connector for WebSphere to work in a multi-domain directory server with a non-unique login ID in the different domains.
To accomplish this optional implementation, you use two parameters in the NetPointWASRegistry.properties file:
OB_DnIsUniqueIdentifier=
The default is false. Be sure to set OB_DnIsUniqueIdentifier to true if the DN is being used.
To enable the Connector for WebSphere to work in a multi-domain directory server with a non-unique login ID in the different domains, you also need the following parameter in the webgate.properties file:
OB_DnIsUniqueIdentifier=false
This optional parameter is used when the TAI module is configured to pass on the users DN instead of the userAttr or LoginID. The default is false. If the OB_DnIsUniqueIdentifier parameter is set to true, the DN is used to communicate between the TAI and Registry. Be sure to set the OB_DnIsUniqueIdentifier to true if the DN is being used.
Note:
The NetPointRegistry.properties and webgate.properties files must be synchronized.The optional implementation described in the previous paragraphs works with the following caveats:
Using TAI or WebGate as the only means of authentication should not be an issue since it is likely to be a requirement for multi-domain authentication. No users can go directly to WAS applications.
Note:
An exception is when logging into the Identity System Administration Console.A unique ID is used for the WAS_ADMIN Account across all domains.
This solution causes a loss of functionality regarding mapping individual users to roles.
On WAS 5, role mapping can be done only through Identity System groups.
The following sections discuss issues to consider when implementing the Connector for WebSphere on Active Directory:
Configuring the Connector for WebSphere for an Active Directory Forest
Set Active Directory Domain in NetPointWASRegistry.properties
The steps to configure the Connector for WebSphere for an Active Directory Forest follow.
To configure the Connector for an Active Directory forest
In the Access System Console, create a new Basic Over LDAP authentication scheme for a domain in the Active Directory Forest.
The base credentials that you specify in the Plugin(s) field must be the same as the search base that you specified in the directory server profile.
If you already created an administrator during pre-installation setup, you do not need to complete step 2. See "Preparing to Install the Connector" for more information.
Create a WebSphere administrator in Oracle Access Manager with View and Delegated Administration rights.
Ensure that the administrator's login identification is unique.
Specify the WebSphere administrator as the administrator for the Active Directory forest domain.
This domain must be the same as the one for which you created the authentication scheme in Step 1. To do this, specify values for the OB_WebPassADDomain parameter in the NetPointWASRegistry.properties file as described in Table 11-1.
You can search for users in the parent domain but you cannot search for users in sibling or children domains.
Note:
You do not need to create an administrator for every domain in an Active Directory Forest.If you are running Active Directory using multiple domains, you must manually edit the NetPointWASRegistry.properties file to include a value for the OBWebPassADDomain parameter.
For example, OBWebPassADDomain=dc=xyz, dc=acme, dc=com
The domain must be the same as the domain defined for the default directory server in Oracle Access Manager.
See the Oracle Access Manager Identity and Common Administration Guide for more information.
#OB_UserAttr should be the Login Attribute example LoginID which is uid or genuserid.
The following is a list of the most frequently asked questions on the Connector for WebSphere. See also, "Troubleshooting the Connector for Portal Server v5".
Problem
When I try to enable administrative or application security, I receive the following error:
You must supply the primary administrative user name on the active registry or realm panels to enable security. The server user ID or password is not specified. Enter a server user ID and password for the active user registry, or select to use the automatically generated server identity on the realm panel.
Solution
This message appears if you have not selected Standalone Custom Registry as the default realm when configuring the Secure Administration, Applications, and Infrastructure settings. See "To enable the NetPointWASRegistry in WAS 6.1" for details.
Problem
I am trying to conduct a search of users or groups using WAS role mapping. I am supplying a search string but I am getting an error message.
Solution
WAS role mapping requires wildcards in all search strings. Put an asterisk (*) at the beginning and the end of your search string, for example, a search of "*user123*" returns all user IDs that have "user123" as a substring.
Problem
I am locked out of WAS 5 Admin Console or the WebSphere 5 Server does not start after making a configuration change. What should I do?
Solution
Restore the previous WAS 5.0 security.xml file located in WAS_install_dir/config/cells/serverName directory. This assumes you have made a backup of an older, working copy.
Problem
On Solaris, when setting up the SSL connector for the Connector for WebSphere, why does the keytool command give a "Signature not available" error?
Solution
This is a jdk 1.2.x problem. Use the NT version or any other jdk1.3.x version to create the cert db (jssecacerts) and then use it with WebSphere on Solaris.
Problem
Why do I get "All the jars are not in classpath: NoClassDefException"?
Solution
Make sure that the NetPointWASRegistry.jar and jobaccess.jar are in the classpath.
Problem
Why do I get an SSLPeerUnverifiedException - peer not authenticated exception?
Solution
The jvm being used is different from the jvm that has imported the certificates of ca and server. The jvm and keytools used must be from the same installation. If one keytool is used to add certificates and java is invoked from the other installation directory, then the jvm will not be able to use the certificates and will produce this exception.
Problem
Why do I get "ObConfig.NO_CONFIG_FILE"?
Solution
his error means that the Access Manager SDK client configuration file is not found. Check the Install_Dir parameter in the NetPointWASRegistry.properties file and ensure that the following points to the NetPointWASRegistry installation directory. For example:
# Installation directory of NetPointWASRegistry OB_InstallDir=/CWS_install_dir/oblix/config/
Problem
Why do I get an UnsatisfiedLinkError?
Solution
You probably do not have the Access Manager SDK lib in the PATH or LD_LIBRARY_PATH depending on the platform.
For example:
On NT: set the PATH as follows:
set PATH=%PATH%;c:\CWS_install_dir\oblix\lib
On Solaris: set LD_LIBRARY_PATH as follows:
setenv LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/CWS_install_dir/oblix/lib export LD_LIBRARY_PATH
This can be either done at system level or at start-up.
For AIX: set LIBPATH as follows:
setenv LD_LIBRARY_PATH=$LIBPATH:/CWS_install_dir/oblix/lib export LIBPATH
You may also get the following error if you do not have the Access Manager SDK lib:
"com.ibm.ejs.exception.InvalidUserRegistryConfigException: Custom [OSName]: com.oblix.registry.NetPointWASRegistry"
Problem
Why do I get NoClassDefFound error for com.oblix.access.ObAccessException?
Solution
Make sure that the jobaccess.jar file is in WebSphere's classpath.
Problem
Why do I not see the ObSSOCookie being set?
Solution
Make sure that you are using fully qualified domain names to access the WebSphere Server and the Web server that is running WebGate.
For example, use:
http://foobar.oblix.com:9080
Not:
http://foobar:9080
Check the Cookie domain for the following:
Ensure that the Primary Cookie Domain set in the WebGate Configuration in Policy Manager.
In the NetPointWASRegistry.properties file, ensure the values for these parameters are set as follows: OB_CookieDomain=.oblix.com, OB_CookiePath=/
Problem
I see the ObSSOCookie, but why is WebPass rejecting it?
Solution
Take the following steps:
Ensure that the time on the machine on which WebGate and Webpass are installed is synchronized with the time on the WebSphere Server.
Make sure that in the authentication schemes for WebGate, Webpass and the WebSphere Server resources have the same security level.
Problem
Why is WebGate rejecting the ObSSOCookie?
Solution
Ensure that the IPValidation parameter is set to Off.
From the Access System Console, click Access System Configuration, click AccessGate Configuration in the left navigation pane, click the link for the WebGate that protects the WebPass, and in the IPValidation field select the Off option.
Problem
Why do IdentityXML calls fail with an unauthorized exception?
Solution
Check the NetPointWASRegistry.properties file to ensure that the WebPass host name is fully qualified.
For example:
OB_WebPassHost=foobar.oblix.com OB_WebPassPort=80
Problem
Why do I get a "server specific error 10" while restarting the WebSphere Administrative Server.
Solution
Ensure all Java process are killed before re-starting the WebSphere Administration Server.
Problem
I see the following exception:
Exception in thread "main" com.ibm.websphere.security. CustomRegistryException: admin at com.oblix.registry.NetPointWASRegistry.getUserDisplayName(NetPointWASRegistry.java:622) at com.oblix.tools.registryTester.main(registryTester.java:69)
Solution
There can be many reasons for this exception. In the NetPointWASRegistry file, turn on the debug flag and check the debug log path as follows.
OB_LogLevel=debug
OB_LogFileName=/oblix/NetPointWASRegistry/log
Problem
I get the following error in the Oracle Access Manager log file:
Mon Jan 06 14:57:21 PST 2003: Error making SOAP request java.io.FileNotFoundException: http://cobalt.oblix.net:80/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi at sun.net.www.protocol.http. HttpURLConnection.getInputStream(HttpURLConnection.java:529) at com.oblix.soapclient.OblixSoapClient.doRequest(OblixSoapClient.java,Compiled Code) com.oblix.registry.NetPointWASRegistry.realGetUserDisplayName (NetPointWASRegistry.java:650) at com.oblix.registry.NetPointWASRegistry.getUserDisplayName( NetPointWASRegistry.java:607) at com.oblix.tools.registryTester.main(registryTester.java,Compiled Code).
Solution
Ensure that the IPValidation parameter is set to Off.
From the Access System Console, click Access System Configuration, click AccessGate Configuration in the left navigation pane, click the link for the WebGate that protects the WebPass, and in the IPValidation field select the Off option.
Problem
I get the following error in the Oracle Access Manager log file:
Mon Jan 20 15:37:24 GMT-06:00 2003: Error making SOAP request java.io.IOException: Server returned HTTP response code: 401 for URL: http://foobar.oblix.com:80/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi at sun.net.www.protocol.http.HttpURLConnection.getInputStream (HttpURLConnection.java:604) at com.oblix.soapclient.OblixSoapClient.doRequest(OblixSoapClient.java:285)
Solution
Be sure that the IPValidation parameter for the WebGate is set to Off.
From the Access System Console, click Access System Configuration, click AccessGate Configuration in the left navigation pane, click the link for the WebGate that protects the WebPass, and in the IPValidation field select the Off option.
Problem
I get the following exception: "com.ibm.ejs.exception.InvalidUserRegistryConfigException: User [username] not authenticated"?
Solution
Make sure the OB_UserAttr, OB_UserSearchAttr and OB_GroupSearchAttr are set correctly in NetPointWASRegistry.properties.
OB_UserAttr=samaccountname
OB_UserSearchAttr=cn
OB_GroupSearchAttr=cn
Problem
I get the following error in the Oracle Access Manager log file:
java.lang.StringIndexOutOfBoundsException: String index out of range: -10 at java.lang.String.substring(String.java(Compiled Code)) at com.oblix.soapclient.OblixSoapClient.handleSoapResponse(OblixSoapClient.java:345) at com.oblix.soapclient.OblixSoapClient.doRequest(OblixSoapClient.java:297) at com.oblix.registry.NetPointWASRegistry.realGetUserDisplayName (NetPointWASRegistry.java:650) at com.oblix.registry.NetPointWASRegistry.getUserDisplayName (NetPointWASRegistry.java:607) at com.oblix.registry.NetPointWASRegistry.getUniqueUserId (NetPointWASRegistry.java:680) at com.ibm.ejs.security.registry.CustomRegistryImpl.createCredential (CustomRegistryImpl.java:698) at com.ibm.ejs.security.registry.CustomRegistryImpl.authenticate (CustomRegistryImpl.java:166) at com.ibm.ejs.security.registry.RegistryBean.authenticate (RegistryBean.java:109) at com.ibm.ejs.security.registry.EJSRemoteStatelessRegistry.authenticate(EJSRemoteStatelessRegistry.java:25) at com.ibm.ejs.security.registry._Registry_Stub.authenticate(_Registry_Stub.java:275) at com.ibm.ejs.security.ltpa.LTPAServerObject.authenticate(LTPAServerObject.java:97) at com.ibm.ejs.security.util.LTPAAuthenticationCache.update(LTPAAuthenticationCache.java:167) at com.ibm.ejs.security.util.Cache.get(Cache.java:114) at com.ibm.ejs.security.util.LTPAAuthenticationCache.getCredential(LTPAAuthenticationCache.java:82) at com.ibm.ejs.security.SecurityServerBean.authenticateBasicAuthData(SecurityServerBean.java:145) at com.ibm.ejs.security.EJSRemoteStatelessSecurityServer.authenticateBasicAuthData(EJSRemoteStatelessSecurityServer.j ava:49) at com.ibm.ejs.security._SecurityServer_Stub.authenticateBasicAuthData(_SecurityServer_Stub.java:281) at com.ibm.WebSphereSecurityImpl.SecurityServerImpl.authenticateBasicAuthData(SecurityServerImpl.java:69) at com.ibm.ISecurityLocalObjectLTPAImpl.PrincipalAuthenticatorImpl.authenticate(PrincipalAuthenticatorImpl.java:437) at com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl.request_login_controlled(LoginHelperImpl.java:1092) at com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl.request_login_controlled(LoginHelperImpl.java:827) at com.ibm.ISecurityLocalObjectBaseL13Impl.CredentialsImpl.get_mapped_credentials(CredentialsImpl.java:1206) at com.ibm.ISecurityLocalObjectBasicAuthImpl.CredentialsImpl.get_mapped_credentials(CredentialsImpl.java:188) at com.ibm.ISecurityLocalObjectBaseL13Impl.VaultImpl.setServerCred(VaultImpl.java:3862) at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthenticatorImpl.setServerCred(PrincipalAuthenticatorImpl.java:9 79) at com.ibm.ISecurityLocalObjectLTPAImpl.PrincipalAuthenticatorImpl.authenticate(PrincipalAuthenticatorImpl.java:302) at com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl.request_login_controlled(LoginHelperImpl.java:1092) at com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl.request_login_controlled(LoginHelperImpl.java:827) at com.ibm.ISecurityLocalObjectBaseL13Impl.CredentialsImpl.get_mapped_credentials(CredentialsImpl.java:1206) at com.ibm.ISecurityLocalObjectBasicAuthImpl.CredentialsImpl.get_mapped_credentials(CredentialsImpl.java:188) at com.ibm.ejs.security.SecurityCollaborator.getActualCredential(SecurityCollaborator.java:999) at com.ibm.ejs.security.SecurityContext.getActualCreds(SecurityContext.java:75) at com.ibm.ejs.security.Initializer.bindServerIdToAdminApp(Initializer.java:458) at com.ibm.ejs.security.Initializer.initialize(Initializer.java:217) at com.ibm.ejs.security.Initializer.serverStarted(Initializer.java:133) at com.ibm.ws.runtime.Server.fireServerStarted(Server.java:2001) at com.ibm.ws.runtime.Server.fireServerStarted(Server.java:1994) at com.ibm.ejs.sm.server.AdminServer.initializeRuntime0(AdminServer.java:1144) at com.ibm.ws.runtime.Server.initializeRuntime(Server.java:884) at com.ibm.ejs.sm.server.AdminServer.main(AdminServer.java:392) at java.lang.reflect.Method.invoke(Native Method) at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:158)
Solution
Make sure the Identity Server is up and running.
Problem
Why does the Portal Server allow logins with old passwords even though it honors passwords updated through Oracle Access Manager?
Solution
Because the Portal Server installation sets the Security Cache Timeout to 600 seconds, old passwords will be stored in cache for that amount of time. This parameter is present in the WebSphere Application Server Administrative Console - Security Center and under the General tab.
Problem
A deactivated Oracle Access Manager user can still access WebSphere resources.
Solution
To avoid this, ensure that all authentication schemes that WebSphere uses have the following lines added:
(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED))
Problem
Why does the WebSphere Portal Server not come up, resulting in security exceptions?
Solution
Ensure that the LPTA Token domain is set up correctly.
Problem
Single sign-on is not working when a URL resource is protected with a Basic Over LDAP authentication scheme, even though TAI is enabled.
Solution
Verify the you followed the steps described in "Configuring the TAI for WebSphere v5", and that you have set the challenge re-direct field in the Basic Over LDAP authentication scheme.
Problem
The following error appears in the Event Viewer of the WebSphere Administrative Console:
CNTR0020E: Non-application exception occurred while processing method isAllLevelNone on bean BeanId(admin#repository.jar#PmiService, null):javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0 No; nested exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: minor code: 0 completed: No org.omg.CORBA.TRANSACTION_ROLLEDBACK: minor code: 0 completed: No at com.ibm.ejs.jts.jts.JBrokerSupport$RI.client_unmarshalled_reque st (JBrokerSupport.java:405) at com.ibm.CORBA.iiop.RIs.iterateClientRequestPreRIs(RIs.java (Compiled Code)) at com.ibm.CORBA.iiop.ClientRequestImpl.reInvoke (ClientRequestImpl.java:851) at com.ibm.CORBA.iiop.ClientDelegate.invoke (ClientDelegate.java:894) at com.ibm.CORBA.iiop.ClientDelegate.invoke (ClientDelegate.java:409) at org.omg.CORBA.portable.ObjectImpl._invoke (ObjectImpl.java:258) at com.ibm.ejs.sm.agent._AdminAgent_Stub.invokeActiveObject (_AdminAgent_Stub.java:39)
Solution
This may occur if the WebSphere Application Server startup time is long. There can be multiple reasons for this problem, including a startup servlet (load-on-startup = true) which requires long time performing the init() method for the servlet.
If the Ping Initial Timeout is set to a value lower than the amount of time needed for the App Server to start, the Ping Initial Timeout alarm expires before the App Server could come up fully and send the "serverIsAlive" message. As a result, the administration server tries to kill and restart the Application Server process. In this situation, the state of the clone is recorded as Running.
The PMI client indicates that the clone is up and running and tries to invoke the "isAllLevelNone" method on the clone. Because the clone does not exist, it fails with an error message.
To correct this, set the Ping Initial Timeout to a larger number to allow the Application Server to start completely.
Problem
After enabling security and configuring LDAP as the Authentication Mechanism, the administration server restarts, the following errors show in the trace file:
[02.03.21 08:37:59:957 CST] 4be2cc Initializer W SECJ0007E: Error during security initializationjava.lang.NullPointerException at com.ibm.ejs.security.ltpa.LTPAPrivateKey.decode(LTPAPrivateKey.java:50) at com.ibm.ejs.security.ltpa.LTPAPrivateKey.<init>(LTPAPrivateKey.java:40) at com.ibm.ejs.security.ltpa.LTPAServerBean.updateAll(LTPAServerBean.java:106) at com.ibm.ejs.security.Initializer.updateActiveLtpaConfig(Initializer.java:392) at com.ibm.ejs.security.Initializer.propagateSecurityConfig(Initializer.java:296) at com.ibm.ejs.security.Initializer.initialize(Initializer.java:173) at com.ibm.ejs.security.Initializer.serverStarted(Initializer.java:129) at com.ibm.ws.runtime.Server.fireServerStarted(Server.java:1977) at com.ibm.ws.runtime.Server.fireServerStarted(Server.java:1970) at com.ibm.ejs.sm.server.AdminServer.initializeRuntime0(AdminServer.java:1123) at com.ibm.ws.runtime.Server.initializeRuntime(Server.java:882) at com.ibm.ejs.sm.server.AdminServer.main(AdminServer.java:391) at java.lang.reflect.Method.invoke(Native Method) at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:158)[02.03.21 08:38:00:001 CST] 4be2cc Server A WSVR0023I: Server __adminServer open for e-business
Solution
Sometimes the key and password get out of sync. Create a new key for WebSphere's use.
To create a new key, do as follows:
From the Security Center (4.0x) or the Global Security Wizard (3.5x) under the Authentication Tab, click Generate Keys.
At the prompt, enter a password for the new key.
Problem
A user's attempt to log in to the WebSphere Administrative Console results in the following error:
ADGU2009E: Security Error: Either username/password is wrong or this user is not authorized to connect to admin server.
Solution
Only the following users can log in to the WebSphere Administrative Console when security is enabled:
User defined in the security ID of the custom registry/LDAP.
Users defined in Administrative roles.
Problem
I get a Not Authorized error when I try to access a WAS resource or a WebSphere Portal resource.
Solution
You get this error because the ObSSOCookie is not being sent. Refresh the page to send the ObSSOCookie.
It is recommended that you use a form-based authentication scheme to avoid this problem. If you use the basic authentication scheme, set the Challenge Redirect field to another WebGate to ensure that the ObSSOCookie gets sent.
Problem
If TAI is failing with a stack trace:
... 1493ff35 JaasLoginHelp E SECJ4001E: Login failed for testeisintuser/Default Realm ....
You get this error because the ObSSOCookie is not being sent.
Solution
Do the following:
Refresh the page to send the ObSSOCookie.
Enable further security debugging for the following classes:
com.ibm.ws.security.*
com.ibm.websphere.security.*
com.ibm.WebSphereSecurityImpl.*
SASRas
To view detailed information on the runtime behavior of security, enable trace on the following components and review the output:
com.ibm.ws.security.*=all=enabled:com.ibm:WebSphereSecurityImpl.*=all=enabled:com.ibm.websphere.security.*=all=enabled.
This trace statement collects the trace for the security runtime:
com.ibm.ws.console.security.*=all=enabled.
This trace statement collects the trace for the security center GUI.
SASRas=all=enabled.
This trace statement collects the trace for SAS (low-level authentication logic):
The logs should give better debugging messages, and ideas on what exactly is failing.
Problem
Error in the TAI logs:
Error no action found
Solution
Ensure that the Authentication Scheme level for the Authentication scheme protecting the WebSphere Policy (Authen/Basic) is less than or equal to the Authentication scheme level protecting the WebSphere resource.
Ensure that the WAS_REGISTRY action is set properly (see "Defining a Policy Domain for WebSphere"). Ensure that there is an Authorization Expression set and that upon Authorization success the WAS_REGISTRY action is set.
Problem
WAS Registrytester.bat may fail:
System variables may be picking up an older version of obaccess.dll based on the path.
Solution
Check your system variables to ensure these are correctly set. For example, $PATH and $CLASSPATH must be correctly set.
Problem
Unable to search users in the WebSphere Portal Admin page.
Solution
Do the following:
Log in as wpsadmin and go to Portal Administration, Security, Access Control List.
Click Get groups and users. Search for users using the wildcard character "*" and select wpsadmin and add it to the list, then click OK.
Select user groups in the Select the objects for the permissions for the user wpsadmin, then click Go.
Give Manage permissions for the group All authenticated users for user wpsadmin, then click Save.
Go to Users and Groups, Manage Users, then search for users using the wildcard character "*." to display all the users.
To view groups, repeat steps a, b, and c, then give Manage permissions for each group that needs to be viewed for wpsadmin and click Save
Problem
IBM WebSphere Portal Server gives an error "No Portlets to display"
Solution
Do the following:
Log in to WebSphere Administrative Console. Navigate to WebSphere Portal application.
Click the JVM settings tab and add the following to the System Properties"
"HttpSession.RecurseThroughProxy", value = "true"
Restart the WebSphere Portal application.
The following Portal Server v5 issues are covered:
There are several Portal Server installation-related issues that you may encounter. See the following problem and solution descriptions.
Problem
Both the WebSphere AppServer and Portal Server installed successfully but not able to access Portal Server page i.e. wps/portal.
Solution
Check for the fix packs needs to be applied on Application Server for the respective Portal Server version integration. The order to apply fix packs is important.
For Example, In case of Application Server 5.0 and Portal Server 5.0, the Fix Pack 1 needs to be applied on WebSphere Application server. The order of applying patch would be,
Wasfp1
Pmefp1
Fixes
Manualfixes
You can check $WAS_install_dir/properties/version/history folder to confirm the list of fixes applied on Application server.
For more information on this, see the WebSphere Portal infocenter document available on the IBM WebSphere site.
Problem
On login to the Portal Server (wps/portal), the following error message displayed:
There has been an application error! Please contact to your system administrator to report this error.
Solution
Ensure the required fix pack has been applied on the Application Server. See the first problem in this section. Also, ensure the Java 2 security is disabled in the WebSphere Application server.
To disable Java 2 security
Login into WebSphere Application Server Console, Security, Global Security.
Disable the check box for the Enforce Java 2 Security option.
Save the changes, then restart both the WebSphere Application Server and Portal Server.
Note:
It is recommended that you install Portal Server with disabling Global Security in WebSphere Application server.Problem
On successful login to the Portal Server, the Portal Admin is not able to view the Administration link to manage the Portal Server. This link is displayed on the top-right side of the page.
The Administration portlet is not deployed on the system.
Solution
Do the following:
Run WPSconfig.{bat | sh} portlets script to deploy the same.
This script is available in $WPS_install_dir/config folder. For more information check the wpsconfg.xml file.
Restart the Portal Server and login using admin credentials.
The Portal Admin user will able to see the "Administration" link and he can setup the Portal Server Application.
Note:
The same script will also deploy some sample portlet applications come along with Portal Server installation. Also, WPS_install_dir is the directory where the Portal Server is installed.Problem
On successful login to the Portal Server, Portal Admin is not able to view a portlet page. The error message appears as:
There is no content available. Please check if there is content defined for the markup of your client device.
This message comes because portal page is not created in the Portal Server.
Solution
A page has to be created in the Portal Server so you can add portlets on this page.
To add a page, you need page addition/modification privileges and a portlet needs to be installed that adds a new page or edits a page.
See issue 3 to check whether the required portlet has been deployed on the system.
Problem
When searching users from the Portal Server "user search" interface you may get empty records as a search result. This problem occurs when user names stored in the directory server are in Latin ISO-8859-1 style.
Solution
Ensure that you unset the following environment variables.
unset LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME
The following issues are related to custom security integration.
Problem
Portal Server configuration has been done for a custom member repository (WAS Connector) but the user is still not able to log in into the Portal Server using Custom Data Store user id, that is, the user is present in Oracle Access Manager.
Solution
Check $WPS_install_dir\shared\app\wmm\ wmm.xml file. Confirm that ProfileRepository tag has been configured correctly for Custom Member Repository implementation.
Sometimes WPSconfig script execution modifies wmm.xml file and LDAP settings replace custom member repository settings.
Note:
Oracle recommends that you always keep backup of wmm.xml file configured for Custom Member Repository.Problem
Portal Admin is able to search for the user present in Custom Data Store but on assigning him a portlet access permission, that user is not able to view the portlet after successful login.
This problem occurs when user DN present in the Custom Data Store contains intermediate spaces.
For Example, cn=Portal User, o=company, c=us.
WebSphere Portal does normalization of DN before matching it with the allowed user DN present in its internal cloudscape database. As string entries do not match, access permissions to the user fails.
Solution
To overcome this problem, apply Fix Pack PQ93461 provided by IBM.
Problem
How can I retrieve only the first 10 entries (or the number of entries I want to retrieve) on a search for an Identity system user or group through the Portal Server.
Solution
he parameter of number of records to retrieve is configurable in NetpointWASRegistry.properties file.
The name of parameter is OB_WebPassXPIRecordsReturned.
If this parameter is not defined or set to zero then it will retrieve all the users or groups present in the Oracle Access Manager Repository.
Problem
Portal Admin user is not able to install a portlet.
This problem is related to invalid deployment credentials in Portal Server.
Solution
Verify that WPSConfig.{bat/sh} action-create-deployment-credentials script has been executed or not.
This script execution creates required Credential Vaults in portal server.
Before execution of this script, verify wpsconfig.properties file. Check values of all the configuration parameters mentioned in the Oracle Access Manager Installation Guide.
Also verify that $WPS_install_dir\ shared\app\config\services\VaultService.properties contains correct systemcred.dn value. This should be Portal Admin User DN.
After successful execution verify that the credentials vaults has been created for the Portal Server.
You can check the same from Portal Server Login, Administration, Access, Credential Vault, Manage System Vault Slots.
Problem
How can I get the debug logs of the Oracle Access Manager WAS Registry and CMR?
Solution
For WAS Registry logs, set the following parameters of NetpointWasRegistry.properties file:
OB_LogLevel=debug
OB_LogFileName=log file complete path
For enabling CMR logs and Portal Server logs set the following parameters in $WPS_install_dir\ shared\app\config\log.properties file.
traceString=*=all=enabled
com.ibm.wps.services.puma.*=all=enabled:
com.ibm.wps.puma.*=all=enabled:
com.ibm.wps.command.puma.*=all=enabled:
com.ibm.wps.engine.commands.*=all=enabled:
com.ibm.wps.services.authentication.*=all=enabled:
com.ibm.ws.security.*=all=enabled:
com.ibm.websphere.security.*=all=enabled
All the puma services logs will be generated in the "Trace.log" file.
Refer Portal Server infocenter document for more details on turning on logs.
Problem
How can I stop/start WebSphere Application Server and Portal Server?
Solution
To start and stop Application Server use
Run the startServer command, as follows:
$WAS_install_dir/bin/startServer name_of_app_server
(Default name is server1)
Run the stopServer command, as follows:
$WAS_install_dir/bin/stopServer name_of_app_server -username WAS_Admin_userid -password WAS_Admin_Pwd
To start and stop Portal Server use
Run the startServer command, as follows:
$WAS_install_dir/bin/startServer name_of_portal_server
(Default name is WebSphere_Portal)
Run the stopServer command, as follows.
$WAS_install_dir/bin/stopServer name_of_portal_server -username PortalAdmin -password PortalAdminPwd
Problem
Portal Admin is not able to search the users present in the Oracle Access Manager Repository but these users are able to log in into the Portal Server.
Solution
Solution: Check the user.fbadefault.filter parameter in the PumaService.properties file. This parameter should contain the attribute name, which is passed to the custom CMR implementation. The WAS Connector uses this attribute to ensure the Portal Admin user is a valid user.
Check the trace.log file for exception details.
Problem
While starting the Portal Server, the CMR gets invalid Portal Administrator credentials.
Solution
Run the Wpconfig. {bat/sh} action-secure-portal-ldap script from the $WPS_install_dir/config folder.
Problem
Why am I unable to install a portlet using the administrator ID with Oracle Access Manager security enabled?
Solution
Solution: Complete the following steps to ensure that the proper credentials are being used.
Verify that the correct values for WasUserid and WasPassword are present in the following file:
wpconfig.properties
WasUserid must be the administrative user id and not the administrative DN. As necessary, use any plain-text editor to open wpconfig.properties and correct the values for WasUserid and WasPassword. Save and close wpconfig.properties.
Confirm that you have executed the following command:
wpconfig.bat\.sh action-create-deployment-credentials
If you discover that you have not run the command, execute it, then proceed with portlet installation.
If you discover that you previously ran the script using incorrect values for WasUserid or WasPassword, correct the invalid values by executing the following two commands:
wpconfig.bat\.sh action-remove-deployment-credentials
wpconfig.bat\.sh action-create-deployment-credentials
Verify that the administrator id is defined correctly by navigating to Portal Administration, Access, Credential Vaults, Manage system vault slots, deployment.user.Vault.
Problem
For WebSphere 6.0, no users are returned when a search is conducted through the WebSphere Application Server Administration Console.
Typically, the Oracle Access Manager log will contain an error message that begins with the following:
Error making SOAP request . . .
Solution
Make sure that $LANG and all $LC_* variables are set to en-US. You can check the current values of these variables through the "locale" command on SLES 9.
Problem
The Client Cert Authentication feature for the WebSphere Application Server 6.0 is unable to access the Snoop applet on the https port of the Web server.
Solution
Ensure that the SSL port used by the Web server has been added to the "default_host" virtual host configuration on the Application Server. If it does not exist, perform the following steps:
Launch the WebSphere Administration Console.
Navigate to Environment, Virtual Hosts, default_host, host aliases.
Add the hostname * Port: 443 (This is the SSL port used by the Web server).
Save your changes.
Regenerate the plugin by completing the following steps:
Navigate to Servers, Web servers.
Select the Web server for which you will create the plugin.
Select Generate Plugin.
You can view the generated plugin by navigating to: WebServerName, plugin properties, View, PlugInFileName.
Restart the Web server.
To verify that the SSL port is operational, complete the following steps:
Disable the Access System policy protecting the test resource.
Attempt to access the test resource using WebSphere Authentication exclusively.
Use the following URL:
https://WebServerHostMachineName:sslPortNumber/snoop
If this succeeds, re-enable the Access System policy.
