9 Integrating the Security Provider for WebLogic SSPI

9.1.1 WebLogic and Oracle Access Manager Integration Points

The WebLogic security framework provides Security Service Provider Interfaces (SSPIs) to protect J2EE applications. The Security Provider takes advantage of these SSPIs, enabling you to use Oracle Access Manager to protect WebLogic resources via:

• User authentication

• User authorization

• Role mapping

The Security Provider consists of several individual providers, each of which enables a specific Oracle Access Manager function for WebLogic users:

Authenticator: This security provider uses Oracle Access Manager authentication services to authenticate users who access WebLogic applications. Users are authenticated based on their credentials, such as user name and password.

The security provider also offers user and group management functions. It enables the creation and deletion of users and groups from the BEA WebLogic Application Server. It also provides single sign-on between WebGates and portals.

Identity Asserter: Like the Authenticator, this security provider uses Oracle Access Manager authentication services to validate already-authenticated Oracle Access Manager users using the ObSSOCookie and to create a WebLogic-authenticated session.

Whether you use the Authenticator or the Identity Asserter depends on your deployment scenario. See "Integration Architecture" for details.

Authorizer: This security provider uses Oracle Access Manager authorization services to authorize users who are accessing a protected resource. The authorization is based on Oracle Access Manager policies.

Role Mapper: This security provider returns security roles for a user. These roles are defined in Oracle Access Manager, and they are provided by Oracle Access Manager using return actions on a special authentication policy. This authentication policy contains a resource with a URL prefix of /Authen/Roles. Role Mapper maps these roles to predefined security roles in WebLogic.

Deployment Provider: This security provider monitors the applications that are deployed or undeployed on the WebLogic Server and writes information about these applications to either NetPointDeployPolicy.txt or NetPointUndeployPolicy.txt. The files store details about the resources, like resource type, Role names to which access is allowed and the like. Details will vary based on the type of the resource. The NetPointPolicyDeployer tool uses these files to create access policies in the Policy Manager.

A special authorization rule for administrators in Oracle Access Manager provides access to the WebLogic applications described in NetPointDeployPolicy.txt. This means that the policies created by the NetPointPolicyDeployer tool in the Policy Manager will have authorization rules in which only administrator have allow access rights.

9.2.1 Authentication for Mixed Web and Non-Web Resources

In this scenario, WebLogic resources, including both Web and non-Web applications, are protected using Oracle Access Manager authentication and authorization schemes. The J2EE Web applications have been configured with deployment descriptors for basic or form authentication. The Identity Asserter need not be configured. The ObSSOCookie is required to achieve the SSO functionality between Web resources. AccessGate generates the ObSSOCookie when the user is authenticated, and AccessGate handles all the communications between the Security Provider and the Access Server. AccessGate processes the ObSSOCookie and sets it in the HTTP header. The Security Provider then uses this cookie and authenticates and authorizes the user.

Figure 9-1 Mixed Web and non-Web Resources (Basic and Form Authentication)

Process overview: User authentication, mixed resource types

1. A user attempts to access a Oracle Access Manager-protected WebLogic resource.

2. The WebLogic Server challenges the user for a username and password (not Oracle Access Manager) using a predefined WebLogic login form because the application's deployment descriptor requires authentication from the container.

   You may use your own login form, which must be customized for WebLogic as described in "Adding Authentication Methods to web.xml".

3. The WebLogic Server forwards the username and password to the Security Provider for authentication and authorization.

4. The Authentication Provider uses the AccessGate to communicate with the Access Server to verify the user's identity.

5. If authentication is successful, the Role Mapping Provider uses the AccessGate to communicate with the Access Server to determine what Oracle Access Manager-defined roles are assigned to this user. These roles are mapped to security roles in WebLogic. In Oracle Access Manager, these roles are configured as a return action when getting an authorization policy for /Authen/Roles. The return actions can be configured in two ways:

   • Static: By entering constant values for name and return value.

   • Dynamic: By configuring a user profile attribute as the return value.

6. The Authorization Provider uses the AccessGate to ask the Access Server to verify that the user has permission to access the requested resource.

   The policies that protect resources are specified in the Policy Manager application in Oracle Access Manager. Policies that are defined in web.xml are not be honored when the Oracle Access Manager's NetPoint Authorization Provider is in effect. This provider supports retrieving external data for authorization. See "Authorization Data from an External Source" for details.

7. If authorization is successful, the WebLogic Server enables the user to access the requested resource. The ObSSOCookie is set so that when the user attempts to access additional Oracle Access Manager-protected non-WebLogic resources, re authentication is not performed.

In this scenario, if the ObSSOCookie is already set and the user has logged in using form-based authentication, the user is logged in without being challenged. You can configure this type of integration by providing additional logic as illustrated in the sample file WebLogic login.jsp. You provide the additional logic in a file called NetPointSSO.jsp, which is provided in the installation directory.

For details about the ObSSOCookie, see the Oracle Access Manager Access Administration Guide.

9.2.2 Authentication for Web-Only Resources

In this scenario, all types of authentication schemes supported by Oracle Access Manager can be used, including those that require identity assertion (also called perimeter authentication), using the ObSSOCookie as the basis of the authentication. A proxy server running WebGate is installed to protect the WebLogic Server. The WebGate performs all of the authentications and authorizations. Identity assertion is used for authenticating Web applications in WebLogic.

This scenario only supports Web applications.

Figure 9-2 Security Provider Scenario for Client Cert Authentication

Process overview: User authentication, Web-only applications

1. A user attempts to access an Oracle Access Manager-protected Web application that is deployed on the WebLogic server.

   The application has an authen-method deployment descriptor configured to CLIENT-CERT.

2. WebGate intercepts the request and queries the Access Server to check if the resource is protected.

3. If the resource is protected, WebGate challenges the user for credentials based on the type of Oracle Access Manager authentication scheme configured for the resource.

4. The user presents credentials such as user name and password, or a certificate.

5. If the user authenticates successfully, WebGate generates an ObSSOCookie, appends this in an HTTP header; the Web server forwards this HTTP request to the WebLogic proxy plug-in which forwards the request to the WebLogic server.

   In this case, the HTTP response object is set in the header, not in the ObSSOCookie.

6. The WebLogic proxy plug-in passes the cookie in the HTTP header to the WebLogic Server.

7. The WebLogic Server's security service invokes the Identity Assertion Provider.

   The Identity Assertion Provider expects the ObSSOCookie as an external token for validating the user. The Asserter sets the cookie in the HTTP response object once it validates the token.

8. The Identity Assertion Provider extracts the ObSSOCookie information from the HTTP header, validates the ObSSOCookie, and retrieves the user identity from the Access Server using a return action defined in a special authentication scheme in Oracle Access Manager. A resource with the URL Prefix /Authen/Basic is protected by Oracle Access Manager and is used by the Security Provider SSPI connector internally to authenticate users.

9. The remaining steps are the same as for "Process overview: User authentication, mixed resource types", step 5 - step 7.

9.2.3 Authentication for the Portal

Oracle Access Manager 10g (10.1.4.0.1) supports integration with the WebLogic Portal Server.

The following scenario assumes that the environment configuration does not use a proxy Server running a WebGate. In this scenario, the resource is not required to be a Oracle Access Manager-protected resource because the Security Provider does not participate in authorizing access to Portal Server resources.

The Security Provider internally authenticates the resource against the configured resource /Authen/Basic. The Portal application needs to be an application protected by WebLogic with username and password authentication.

As mentioned earlier, when a request is made for any of the resources deployed on WebLogic Server, control goes to WebLogic Server which in turn launches the login page for the application. In the case of the Portal Server, Oracle does not implement the Authorization Provider and therefore does not have access to the HTTP response object. As a result, Oracle Access Manager is not be able to set the ObSSOCookie once a user is authenticated. Instead the Security Provider uses its own login filter and you need to modify the JSPs. For more information, see "Process overview: User authentication for the Portal".

Figure 9-3 User authentication for the Portal

Process overview: User authentication for the Portal

1. A user attempts to access a WebLogic resource that is protected by Oracle Access Manager.

2. The WebLogic Server challenges the user for username and password.

3. The WebLogic Server forwards the username and password to the Security Provider for authentication.

4. The Authentication Provider uses the AccessGate to communicate with the Access Server to verify the user's identity.

   If authentication is successful, the Authentication Provider sets the subject correctly and passes control to WebLogic for Role Mapping and Authorization.

5. WebLogic displays the Portal application, on the basis of the authorization granted to the various portlets, etc. in the Portal Application.

Single sign-on: Single sign-on between Oracle Access Manager-protected non-WebLogic resources to WebLogic Resources and vice-versa can be achieved for Portal Web Applications that are authenticated using a login portlet.

To achieve this, additional logic must be added in form of NetpointPortalSSO.jsp to the login jsp used by the login portlet, and the POST action of the login form must be configured to invoke the Oracle Access Manager login filter class. For single sign-on setup details are given in section, see "Configuring Single Sign-On for the Portal Server".

Process overview: Single sign-on between Oracle Access Manager-protected non-WebLogic resources to WebLogic resources

1. A user accesses Oracle Access Manager-protected non-WebLogic resources and the ObSSOCookie is set.

2. A user accesses a WebLogic resource.

3. The NetpointPortalSSO.jsp, which is included as a part of login jsp, intercepts the ObSSOCookie and authenticates using the ObSSOCookie.

   In this case login form present in login jsp is not displayed.

4. WebLogic authorizes the resources in the Portal Application.

Process overview: Single sign-on between WebLogic resources to Oracle Access Manager-protected non-WebLogic resources

1. A user tries to access a WebLogic resource.

2. The NetpointPortalSSO.jsp, which is included as a part of login jsp, checks for the ObSSOCookie.

   In this case, no cookie is set and the login form present in login jsp is displayed. Authentication occurs using the user login credentials supplied in login.jsp.

3. The user enters their credentials in the login form; the credentials get posted to a Login Filter (ObLoginFilter configured in web.xml).

4. The Login Filter (ObLoginFilter) authenticates the user with Access Manager SDK; if authentication is successful, the Login Filter sets the ObSSOCookie and redirects to the main resource.

   Authentication is not done using WebLogic authentication.

5. The control reaches to login jsp.

   With the ObSSOCookie set, the flow mentioned in "Process overview: Single sign-on between Oracle Access Manager-protected non-WebLogic resources to WebLogic resources" is followed and WebLogic Portal is accessed.

6. The user accesses Oracle Access Manager-protected non-WebLogic resources with the ObSSOCookie set and no re-authentication performed.

9.5.1 Preparing the Environment

Before you install Security Provider for WebLogic, you must complete the following tasks:

Task overview: Before installing the Security Provider for WebLogic

1. Install and set up the WebLogic Application/Portal Server as described in your vendor documentation.

   
   

   Note: Oracle Access Manager supports integration with the WebLogic Portal Server.

   
   

2. Be sure you are using JDK 1.4.

3. Install and set up Oracle Access Manager, as described in the Oracle Access Manager Installation Guide, then:

   In the Access System Console, add an AccessGate and associate it with the Access Server that you installed.

   Add and associate an AccessGate with an Access Server for the Security Provider. You may want to name the AccessGate accordingly; for example, WebLogicProvider.

   
   

   Note: If you are going to use the deployment tool discussed in "Running the NetPoint Policy Deployer", you must turn on the Access Management Service for the AccessGate, as well as all Access Servers associated with the AccessGate.

   
   

4. Create a user in the Identity System who is a WebLogic administrator and give this person delegated administrative rights. See the chapter on policy domains in the Oracle Access Manager Access Administration Guide for details.

5. Install Security Provider as described in "Installing the Security Provider".

9.5.2 Installing the Security Provider

The installation procedure depends on the platform on which you are installing Oracle Access Manager. The following example occurs on a Windows system. However, installation is the same after you launch the installation package for your platform.

To install the Security Provider for WebLogic

1. Locate and launch the Security Provider installation package. For example:

   Oracle_Access_Manager10_1_4_0_1_Win32_BEA_WL_SSPI

   The install wizard launches and the Welcome screen appears.

   If the AccessGate fails during installation, you can run the tool configureAccessGate after installation, which is located in:

   Security_Provider_install_dir\oblix\tools\configureaccessgate

   where Security_Provider_install_dir is the directory where the Security Provider for WebLogic SSPI is installed. See the Oracle Access Manager Access Administration Guide for information on AccessGates and the configureAccessGate tool.

2. On the Welcome screen, click Next.

3. Confirm that you are logged in as a user with administrative rights, then click Next.

4. Select an installation directory and click Next.

5. View the confirmation screen and click Next.

   A set of files are installed. When the installer has completed, you are prompted as to whether you want a Typical or Advanced installation.

6. Select Typical or Advanced and click Next.

7. Continue with the procedure that is appropriate for your environment:

   • "Completing a Typical Installation" .

   • "Completing Advanced Installation" .

9.5.3 Completing a Typical Installation

Typical installations supply default values for the Security Provider configuration.

A typical installation prompts you for a transport security mode. The transport security mode that you select for the Security Provider must match the transport security mode for the Access Server. Information on the prompts for installing in simple and certificate mode are available in the Oracle Access Manager Installation Guide. The prompts for configuring the transport security mode for the Security Provider are similar to those presented when installing any other Oracle Access Manager component.

To finish a typical installation

1. Complete the WebPass details, as follows:

   1. Enter the hostname where webpass is installed.

   2. Enter the webpass port number.

   3. Indicate whether the webpass is protected by a webgate.

   You complete step 2 when the WebPass is protected by a WebGate. Otherwise, proceed to step 3. If you have chosen to use WebGate to protect WebPass, the assumption is that you are protecting the Oracle Access Manager applications with policy domains. Therefore, it is also assumed that single sign-on between these components has been configured correctly.

2. WebPass Protected by WebGate: Complete the following steps.

   1. Enter the cookie domain for the WebGate (for example, .domain.com). The ObSSOCookie is then recognized by all servers within this domain.

   2. Enter the cookie path (/).

3. Complete directory-specific information, as follows:

   1. Specify whether WebPass requires an HTTPS connection.

      This is the SSL for secure connection when WebPass runs on HTTPS.

   2. 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.

   3. Specify the user search attribute.

      This attribute must be the same as the attribute configured for the DN Prefix semantic type for the person object class in the Identity System. The person object class type must a structural object class. The administrator of your directory server sets this search attribute. The user attribute and the user search attribute cannot be the same.

   4. 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 System. The group object class a structural object class. The administrator of your directory server sets the group search attribute.

4. Select a transport security mode:

   • Open: If you select open mode, all data is in plain text.

   • Simple: If you select simple mode, you are prompted to supply a global pass phrase. As in Cert mode, you secure the private key with a Privacy Enhanced Mail (PEM) pass phrase. Before an AccessGate or Access Server can use a private key, it must have the correct PEM pass phrase. The PEM pass phrase is stored in a encrypted file called password.lst. For Simple mode, the PEM pass phrase is the same for each WebGate and Access Server instance.

   • Cert: If you select cert mode, you are prompted to supply a global pass phrase. You are then asked if you wish to request a certificate or install a certificate.

5. Supply information regarding the AccessGate and Access Server that you have installed.

6. Review the readme that appears.

   The information in this readme is covered in this chapter also.

7. Confirm the installation.

8. Continue with "Setting Up WebLogic Policies in Oracle Access Manager".

9.5.4 Completing Advanced Installation

Advanced installation permits you to override the default configuration. All the configuration options that you can set in an advanced installation are provided in the sample configuration file described in "NetPointProvidersConfig.properties". This gives you the opportunity to customize your installation, which can be useful if you have configured several versions of the Security Provider authentication and authorization schemes.

To finish an advanced installation -- COREid Security Provider?

1. Complete the screen subtitled "Oracle Security Provider" to use a special policy to authenticate users in WebLogic. Specify the following:

   • Resource Type: This is the name of a resource type used by the Security Provider to authenticate users.

     See "To configure the WebLogic resource types" for details.

   • Resource Name: This is the URL prefix for the resource used by the Security Provider to authenticate users.

     See "To add resources to the domain in Oracle Access Manager" for details.

   • Resource Name used for Anonymous Access: This is the URL prefix for the resource used when allowing anonymous access to certain resources.

     See "To add resources to the domain in Oracle Access Manager" for details.

   • Resource operation: This is the operation specified on the resource type definition.

     The operation is performed to authenticate users.

   • Login Parameter for credential_mapping Plug-in of Authentication Scheme:

     See "To create authentication schemes for WebLogic" for details.

   • Password Parameter User for password_validation Plug-in of Authentication Scheme: See "To create authentication schemes for WebLogic" for details.

   • Action Type: Action is configured to get the login ID from the ObSSOCookie. This is the action configured on the authorization rule.

     See "To add authorization and authentication rules to the domain" for details.

   • Action Name: Action is configured to get the login ID from the ObSSOCookie.

     See "To add authorization and authentication rules to the domain" for details.

   • Dummy Username: For Form Login with SSO when there is No WebGate on Proxy HTTP Server.

     This is used if you are protecting both Web and non-Web resources and you are using form login. If the login.jsp is modified to include NetPointSSO.jsp, and the user has already logged in to an Oracle Access Manager-protected resource, the user has received a token. The next time the user tries to access a protected resource, Oracle Access Manager uses the dummy user name as the user name and the token is used as the password. The default is obdummyuser. Oracle recommends that you use the default name.

   • WebLogic resource types used for web applications (comma separated): These are the resource types that WebLogic uses for Web applications.

     See "Mapping WebLogic Resources to Oracle Access Manager Resources" for details.

2. Complete the screen subtitled--name change? "Oracle Security Provider" to use a special policy to get roles for a user.

   Specify the following configuration to set up this policy:

   • TTL (time to live) of elements in roles cache: This is the amount of time the action is preserved in the cache.

   • Time to delete expired elements of cache (in seconds): This is the time interval for freeing the memory used for expired elements in the cache.

   • Resource type: This is the name of a resource type used by the Security Provider to get roles. See "To configure the WebLogic resource types" for details.

   • Resource name: This is the URL prefix for the resource used by the Security Provider to get roles. See "To add resources to the domain in Oracle Access Manager" for details.

   • Resource operation: This is the operation specified on the resource type definition. The operation is performed to authenticate users.

   • Action Type in authorization rule to get roles: This is the action configured on the authorization rule to get user roles. See "To add authorization and authentication rules to the domain" for details.

3. Complete the screen, "Configuration for Oracle Security Provider for WebLogic":

   • Default access to resources not protected by Oracle Access Manager (deny, allow, abstain): Allow grants access, deny forbids it. Abstain means that if there are multiple security providers, WebLogic goes to the next security provider to decide what to do.

   • Map the authorization result ABSTAIN to (allow, deny): A result of abstain can be automatically reset to allow or deny.

   • Set debugging: Debug logs are written to the WebLogic log file.

4. Finish the installation by completing the steps described in "Completing a Typical Installation".

9.5.5 Setting Up WebLogic Policies in Oracle Access Manager

After installing Oracle Access Manager and WebLogic, you need to define Oracle Access Manager policy domains that provide a method for protecting WebLogic applications. The basics of defining a policy domain are:

• Creating resource types: This enables Oracle Access Manager to identify the kinds of WebLogic resources that it should protect and the operations (such as GET) associated with the resource.

• Creating authentication schemes: This enables Oracle Access Manager to verify user identities.

• Creating authorization schemes: This enables Oracle Access Manager to grant users access to the resources that you have defined.

• Creating a policy domain: This creates a container for your WebLogic-related policies.

• Creating policies: These are directives for protecting specific WebLogic resources. Policies are an amalgam of resource type definitions, URLs identifying the resource locations, and the authentication and authorization schemes to apply when users access the resources.

The first step in setting up a policy domain is to define your resources and authentication schemes. These tasks are discussed in the following sections, which assume a basic knowledge of Oracle Access Manager. The Oracle Access Manager Access Administration Guide provides details on tasks described in the following sections.

To configure the WebLogic resource types

1. From the Access System Console, click the Access System Configuration tab, then click Common Information Configuration, Resource Type Definitions.

   The List All Resource Types page appears.

2. From the List All Resource Types page, click Add.

   The Define a new Resource Type page appears.

3. Define and save the first resource type:

   Name: wl_url

   Display name: wl_url

   Resource matching: case insensitive

   Resource operation: GET

   Resource operation (second): POST

4. Define and save the second resource type:

   Name: wl_svr

   Display name: wl_svr

   Resource matching: case insensitive

   Resource operation: BOOT

   Resource operation (second): DEFAULT

5. Define and save the third resource type:

   Third resource:

   Name: wl_adm

   Display name: wl_adm

   Resource matching: case insensitive

   Resource operation: DEFAULT

6. Define and save the fourth resource type:

   Name: wl_ejb

   Display name: wl_ejb

   Resource matching: case insensitive

   Resource operation: EXECUTE

7. Define and save the fifth resource type:

   Name: wl_authen

   Display name: wl_authen

   Resource matching: case insensitive

   Resource operation: LOGIN

8. Define and save the sixth resource type:

   Name: http

   Display name: http

   Resource matching: case insensitive

   Resource operation: GET

   Resource operation: POST

   Resource operation: PUT

   Resource operation: HEAD

   Resource operation: DELETE

   Resource operation: TRACE

   Resource operation: OPTIONS

   Resource operation: CONNECT

   Resource operation: OTHER

To create authentication schemes for WebLogic

1. From the Access System Console, click Access System Configuration, Authentication Management, Add.

2. Create the first authentication scheme to be used by the Security Provider to authenticate users, as follows (which uses the Oracle Access and Identity authentication scheme as a template).

   1. Configure the General tab:

      Name: Oracle WebLogic Access and Identity authentication scheme

      Description: Used to authenticate users who access WebLogic resources.

      Level: 1

      Challenge Method: Basic

      Challenge Parameter: realm:Oracle Access and Identity

      SSL Required: No

      Challenge Redirect: (Leave blank)

      Enabled: (Leave as is)

      
      

      Note: The realm: string on the challenge parameter is required. The text after this parameter can be configured. Also, in the Name field, the "l" in WebLogic must be lowercase to match the name in a NetPointWeblogicTools.properties file that is part of the integration solution. In general, the name of this authentication scheme should be identical (with case sensitivity) to the ObWLAuthenticationScheme.Name parameter in the NetPointWeblogicTools.properties file.

      
      

   2. Save the information on the General tab by clicking Save.

   3. Click the Plugins tab, and use the credential_mapping and validate_password plugins from the existing Oracle Access Manager authentication schemes. In the credential_mapping plug-in, be sure the mapping base and mapping filter use objects that are specific to your environment. Examples:

      credential_mapping      obMappingBase="o=company,c=us",obMappingFilter=      "(&(&(objectclass=inetorgperson)(uid=%userid%))      (|(!(obuseraccountcontrol=*))      (obuseraccountcontrol=ACTIVATED)))"
          validate_password obCredentialPassword="password"
      
      

      where place-holders such as o=company,c=us, and inetorgperson are replaced with values that are valid for your organization.

      After you create at least one plug-in, default steps and a default authentication flow are created automatically.

   4. After creating a plug-in, you can enable the authentication scheme by clicking the General tab, Modify, selecting the Enable option, and clicking Save.

3. Create the second authentication scheme for un-protecting certain resources, such as gif images in WebLogic resources using the following details and the Anonymous authentication scheme as a template:

   General tab:

   Name: Oracle WebLogic Anonymous Authentication

   Description: Used to un-protect gifs, and so on.

   Level: 0

   Challenge Method: Anonymous

   Parameter: (Leave blank)

   SSL Required: No

   Challenge Redirect: (Leave blank)

   Enabled: Yes

   
   

   Note: In the Name field, the "l" in WebLogic must be lowercase to match the name in a NetPointWeblogicTools.properties file that is part of the integration solution. In general, the name of this authentication scheme should be identical (including case sensitivity) to the ObWLNoneAuthenticationScheme.Name parameter in the NetPointWeblogicTools.properties file.

   
   

   Plugins tab:

   Use the credential_mapping plug-in from the pre-configured Anonymous authentication schemes. In the credential_mapping plug-in, be sure the mapping base and mapping filter use objects that are specific to your environment. Use OblixAnonymous as the mapping filter. Example:

   credential_mapping obMappingBase="o=company,c=us",obMappingFilter="    
        (uid=OblixAnonymous)"
   
   

   where place-holders such as o=company,c=us, and uid should be replaced with values appropriate for your environment.

4. Restart the Access Server.

   You are now ready to create the following policies:

   • Basic Authentication Policy: This policy is used internally to authenticate users by evaluating the user name and login. The policy protects resources with a URL prefix of /Authen/Basic.

   • Role-based Authentication Policy: This policy gets user roles. This policy protects resources with a URL prefix of /Authen/Role.

   • Anonymous Authentication Policy: This policy provides anonymous access to gifs, and other resources. This policy protects resources with a URL prefix of /Authen/Anonymous.

   • Anonymous Authentication Policy (second): This policy enables anonymous access for users. This policy protects resources with a URL prefix of /Authen/Anonymous.

   • WebLogic Administrator Policy: This policy enables access to the WebLogic administration console.

   The Oracle-provided Policy Deployer (known as the NetPoint Policy Deployer) can automate this process, or you can create these policies manually.

5. Continue with one of the following discussions:

   • "Running the NetPoint Policy Deployer"

   • "Manually Configuring WebLogic Policies in Oracle Access Manager"

9.5.6 Running the NetPoint Policy Deployer

After you have created your resource types and authentication schemes, you can run the NetPoint Policy Deployer. This tool enables you to:

• Create the policy domain and policies during initial setup of the Security Provider for WebLogic.

  This policy domain uses the resource type wl_authen created in "To configure the WebLogic resource types".

• Create and delete policy domains and policies that protect WebLogic applications.

You need to run this tool at least once for initial setup. Afterwards, you can either manually create policies for applications deployed in WebLogic, or you can run this tool to automatically create them. Refer to the following procedures:

• To prepare for running the Policy Deployer Tool

• To run the Policy Deployer Tool for the first time

• To run the Policy Deployer after the first time

To prepare for running the Policy Deployer Tool

1. Add the following to CLASSPATH:

   • Security_Provider_install_dir/oblix/tools/npWLTools

   • Security_Provider_install_dir/oblix/tools/npWLTools/npWLTools.jar

   • Security_Provider_install_dir/oblix/lib/jobaccess.jar

2. Add the following:

   Security_Provider_install_dir/oblix/lib

   On Windows, you add this to the PATH. On Solaris, you add this to LD_LIBRARY_PATH. On HP-UX, you add this to SHLIB_PATH.

3. Ensure that the following configuration files are copied from Security_Provider_install_dir to the WebLogic domain directory:

   • NetPointProvidersConfig.properties

     See "NetPointProvidersConfig.properties" for details.

   • NetPointResourceMap.conf

     See "Mapping WebLogic Resources to Oracle Access Manager Resources" for details on configuring this file.

To run the Policy Deployer Tool for the first time

1. Review the following configuration file:

   Security_Provider_install_dir/oblix/tools/npWLTools/ NetPointWeblogicTools.properties

   Where Security_Provider_install_dir is the directory where the Security Provider for WebLogic SSPI is installed.

   Be sure that ObWLTools.setupInitialNetPointSSPIPolicies is set to true (the default).

2. If you are running the WebLogic Web applications in Identity Assertion mode, configure the following parameters in the NetPointWeblogicTools.properties configuration file:

   • ObWLWebResource.usingIdentityAssertion

   • ObWLWebResource.proxyPrefix

   See "NetPointWeblogicTools.properties" for details.

3. From the command line, enter the following:

   java com.oblix.weblogic.tools.NetPointPolicyDeployer userid password -- name change? NetPointPolicyDeployer or COREidPolicyDeployer?

   where userid and password belong to the login ID of the Master Oracle Access Manager Administrator. For all the policies that this tool creates, it initially grants access to this userID only. Use JDK 1.4 to ensure that this command works as expected.

4. Go to the Policy Manager and check if the policies are created.

   See "To create a policy domain in Oracle Access Manager" for details on the policy domains and how they should be configured.

5. After running the tool, go to the Access System Console and provide the proper access to the policies that have been created.

   
   

   Note: Setting up security policies in Oracle Access Manager is only required for protection of resources deployed on the BEA WebLogic Application Server. The Security Provider only supports authentication for portals. If you are using the Security Provider in the portal domain, then only the policies required for authentication need to be created. These are created when you run the Policy Deployer for the first time with the ObWLTools.SetupIntialNetPointSSPIPolicies parameter set to true and the ObWLTools.DeployPolicy and ObWLTools.UnDeployPolicy parameters set to false in the NetPointWeblogicTools.properties file. Therefore, for the portal domain, you can ignore the procedure "To run the Policy Deployer Tool for the first time".

   
   

6. Ensure that the policy domain that was just created is enabled in Oracle Access Manager.

7. In the Policy Manager, click My Policy Domains, then click the WebLogic policy domain.

   The status of the policy domain should be enabled.

8. If the status of the policy domain is not enabled, click Modify and enable it.

To run the Policy Deployer after the first time

1. Open the following configuration file:

   Security_Provider_install_dir/oblix/tools/npWLTools/

   NetPointWeblogicTools.properties

   where Security_Provider_install_dir is the directory where the Security Provider for WebLogic SSPI is installed.

2. Be sure that NetPointDeployPolicy.txt and NetPointUndeployPolicy.txt are in the WebLogic domain directory.

   NetPointDeployPolicy.txt is created when applications are deployed from the WebLogic server. NetPointUndeployPolicy.txt is created when applications are undeployed from the WebLogic server. The Security Provider writes security policy data into this file when J2EE applications are deployed or undeployed. The Policy Deployer reads this file to create policies.

3. Set the following:

   • ObWLTools.SetupIntialNetPointSSPIPolicies=false

   • ObWLTools.DeployPolicy=true

   • ObWLTools.UnDeployPolicy=true

   
   

   Note: If the tool completes successfully but there are no policies in the Oracle Access Manager Policy Manager, look in the NetPointDeployPolicy.txt file and the NetPointUnDeployPolicy.txt files to see if the following settings exist for the same resource: ObWLTool.DeployPolicy=true, ObWLTool.UnDeployPolicy=true This can cause the policies for the same resource to be created and deleted from the Oracle Access Manager Policy Manager. If this occurs, set ObWLTool.DeployPolicy=true and ObWLTool.UnDeployPolicy=false while creating policies using the NetPointPolicyDeployer tool.

   
   

4. Follow step 2 - step 5 of "To run the Policy Deployer Tool for the first time".

5. Continue with "Manually Configuring WebLogic Policies in Oracle Access Manager".

9.5.7 Manually Configuring WebLogic Policies in Oracle Access Manager

If you do not wish to use the Policy Deployer tool described in "Running the NetPoint Policy Deployer", you can configure the policies manually in Oracle Access Manager.

Task overview: Manually configuring WebLogic Policies in Oracle Access Manager

1. Create a WebLogic policy domain, as described in "To create a policy domain in Oracle Access Manager" .

2. Add resources to the domain, as described in "To add resources to the domain in Oracle Access Manager".

   Multiple resources can be defined for each resource type configured in "To configure the WebLogic resource types". Resources provide URL prefixes under which various policies can be defined.

3. Add authorization and authentication rules to the domain, as described in "To add authorization and authentication rules to the domain".

4. Define policies within the domain, as described in "To create policies for the domain -- needs verification/correction".

   The URL prefix in the resource and the URL pattern in the policy together form the definition of the data to be protected by the policy.

To create a policy domain in Oracle Access Manager

1. Log in to the Access System.

2. From the Policy Manager, click Create Policy Domain.

3. Define the following policy domain:

   Name: SecuProvForWebLogic

   Description: Policy domain for WebLogic resources.

4. Save this policy domain.

To add resources to the domain in Oracle Access Manager

1. From the Policy Manager, click My Policy domains and select the new policy domain.

2. Click the Resources tab for the policy domain.

3. Click add, then configure, and save the resource for user authentication:

   Resource type: wl_authen

   URL prefix: /Authen/Basic

   Description: Resource used by the Security Provider to authenticate users.

   The resource type was defined in "To configure the WebLogic resource types".

4. Click add, then configure, and save the resource for anonymous access:

   Resource type: wl_authen

   URL prefix: /Authen/Anonymous

   Description: Resource used for anonymous authentication, where a session is created for anonymous users.

5. Click add, then configure, and save the resource for returning user roles:

   Resource type: wl_authen

   URL prefix: /Authen/Roles

   Description: Resource used when the policy is configured to return roles that are mapped to security roles in WebLogic.

6. Click add, then configure, and save the resource for protecting the WebLogic administration console:

   Resource type: wl_url

   URL prefix: /console

   Description: Optional. Protects the WebLogic administration console.

7. Click add, and save the resource for server administration:

   Resource type: wl_svr

   URLprefix: /servername

   Description: Optional. Restricts access for users who perform server administration tasks, such as starting and stopping the server.

   
   

   Note: If you get an error, be sure that these resources are not already used by another policy domain.

   
   

To add authorization and authentication rules to the domain

1. In the Policy Manager, add the resources that you defined in "To configure the WebLogic resource types" to this policy domain. For example:

   Policy Manager, My Policy domains, policy_domain

   Next, you add authorization rules.

2. Click the Authorization Rules tab, click Add, and create the rule for administrators:

   General tab:

   Name: Authz rule for admin

   Description: Authorization rule for an administrator. This rule provides administrator access to WebLogic applications.

   Enabled: Yes

   Actions tab: Leave blank.

   Allow Access tab:

   People: Add users who are allowed to be WebLogic administrators.

3. Click Add, and create the rule for anonymous access:

   General tab:

   Name: Authz rule for anyone

   Description: Provides anonymous access to resources

   Enabled: Yes

   Actions tab: Leave blank.

   Allow Access tab:

   Role: Anyone

4. Click Add, and create the general rule for access:

   General tab:

   Name: Authz Rule for Authen

   Description: Returns the user ID from the ObSSOCookie using the return action configured on the Actions tab.

   Enabled: Yes

   Actions tab:

   Redirect to: Leave blank On Authorization Success

   Return Type: WL_REALM

   Name: uid

   Return Attribute: login ID attribute where this is the attribute in your directory for the user login ID.

   On Authorization Failure Return: Leave blank

   Allow Access tab:

   Role: Anyone.

5. Click Add, and create the rule for returning the user WebLogic role:

   General tab:

   Name: Authz rule for role

   Description: Returns the user's role. These roles are hard-coded on the return actions, and they match administrative roles in WebLogic.

   Enabled: Yes

   Actions tab:

   Redirect to: Leave blank

   On Authorization Success Return:

   Type: WL_REALM

   Name: role1

   Return Value: Admin

   Type: WL_REALM

   Name: role2

   Return Value: Operator

   Type: WL_REALM

   Name: role3

   Return Value: Monitor

   Type: WL_REALM

   Name: role4

   Return Value: Deployer

   On Authorization Failure Return: Leave blank

   Allow Access tab:

   People: People who are allowed to be the WebLogic administrator.

   
   

   Note: The WebLogic administration console requires the administrator to have certain roles. These are hard-coded on the return actions of Authz rule for role, defined in this step. As an alternative, you can allow access to everyone rather than just the administrator, and control access by using a return attribute such as a user profile attribute or a special attribute called obMyGroups that returns all the groups that a user belongs to.

   
   

6. Create a default authorization rule that allows anonymous access, as follows:

   1. Click the Default Rules tab, Authorization Rules, Add.

   2. Select the rule for anonymous access that you created in the previous step.

      This is the rule called Authz rule for anyone.

   3. Click Save.

      If no policy is evaluated, the default rule provides anonymous access to everyone. This can be changed to meet the requirements of your environment.

7. Create a default rule that authenticates users for access to all resources that do not fall under a specific policy, as follows:

   1. Click the Default Rules tab, Authentication Rule, Add.

      The General page appears.

   2. On this page, add the following default rule (or configure another one, if needed for your environment):

      Name: Oracle WebLogic Anonymous Authentication.

      Authentication scheme: Use the authentication scheme you created in "To create authentication schemes for WebLogic".

To create policies for the domain -- needs verification/correction

1. Create policies for this domain from the Policy Manager. For example:

   Policy Manager, policy_domain, Policies tab

2. Add the basic policy for this policy domain:

   General tab:

   Name: Basic authentication policy

   Description: Authentication using basic LDAP username and password.

   Resource type: wl_authen

   Resource operation: LOGIN -- don't see this under Policies Add or Modify

   Resource: /Authen/Basic -- don't see this under Policies Add or Modify

   Authentication Rule tab:

   Name: Basic authentication rule -- Basic Over LDAP?

   Authentication Scheme: Select the basic authentication scheme Oracle WebLogic Access and Identity that you created in "To create authentication schemes for WebLogic".

   Authorization Rule tab: Add the rule Authz Rule for Authen that you created in "To add authorization and authentication rules to the domain".

   
   

   Note: If you are using identity assertion as the authentication mechanism that protects Web applications, see the notes in "Preparing the WebLogic Environment" after configuring your authentication policies.

   
   

3. Add the anonymous access policy for this policy domain:

   Policies, General tab:

   Name: Anonymous authentication policy

   Description: Authenticates anonymous users.

   Resource type: wl_authen

   Resource operation: LOGIN

   Resource: /Authen/Anonymous

   Authentication Rule tab:

   Name: Anonymous authentication rule

   Authentication Scheme: Select the anonymous authentication scheme Oracle WebLogic Anonymous Authentication that you created in "To create authentication schemes for WebLogic".

   Authorization Rule tab: Add the rule Authz rule for anyone that you created in "To add authorization and authentication rules to the domain" .

4. Add the user role policy for this policy domain:

   General tab:

   Name: Role-based authentication policy

   Description: Authenticates users and gets their WebLogic roles

   Resource type: wl_authen

   Resource operation: LOGIN

   Resource: /Authen/Roles

   Authentication Rule tab:

   Name: Role authentication rule

   Authentication Scheme: Select the Oracle WebLogic Access and Identity rule that you created in See "To create authentication schemes for WebLogic".

   Authorization Rule tab: Add the Authz rule for role that you created in "To add authorization and authentication rules to the domain".

5. Add the "unprotect" policy for this policy domain:

   General tab:

   Name: Unprotect policy for gifs and other files

   Description: Allow anonymous access to gif files

   Resource type: wl_url

   Resource operation: GET,POST

   Resource: all (if there are no resources defined, this defaults to all)

   URL pattern: /.../*.gif

   Authentication Rule tab:

   Name: WebLogic Domain Anonymous authentication rule

   Authentication Scheme: Select the Oracle WebLogic anonymous authentication rule that you created in "To create authentication schemes for WebLogic".

   Authorization Rule tab: Add the Authz rule for anyone that you created in "To add authorization and authentication rules to the domain".

6. Add the WebLogic administration console policy for this policy domain:

   General tab:

   Name: Policy for WebLogic admin console

   Description: Allow administrator access to the WebLogic admin console

   Resource type: wl_url

   Resource operation: GET

   Resource: /console

   Authentication Rule tab:

   Name: WebLogic Domain default authentication rule

   Authentication Scheme: Select the Oracle WebLogic Access and Identity rule that you created in "To create authentication schemes for WebLogic" .

   Authorization Rules tab: Add the Authz rule for admin that you created in "To add authorization and authentication rules to the domain".

   For additional information, see the Oracle Access Manager Access Administration Guide.

7. Continue with "Mapping WebLogic Resources to Oracle Access Manager Resources".

9.5.8 Mapping WebLogic Resources to Oracle Access Manager Resources

The NetPointResourceMap.conf file contains mappings of WebLogic resources to Oracle Access Manager resources. These mappings allow both products to recognize each other's resource definitions. Oracle Access Manager recognizes only URLs, whereas each WebLogic resource has different set of elements associated with it. By mapping these resource elements to URLs and operations, all types of resources can be protected through Oracle Access Manager.

After defining your Oracle Access Manager resources, policy domain, and so on, you need to be sure that the WebLogic resources that you want to protect will correspond to the resources that you defined in Oracle Access Manager.

To map WebLogic resources to Oracle Access Manager resources

1. Locate the NetPointResourceMap.conf file. in the directory where the Security Provider is installed.

2. Review the format of this file in "NetPointResourceMap.conf File Format" .

3. Edit the file using information on Oracle Access Manager resource type definitions in "Setting Up WebLogic Policies in Oracle Access Manager".

4. Continue with "Preparing the WebLogic Environment".

###############################################################################
# This file maps Weblogic resources to Oracle Access Manager resources.
# Oracle Access Manager only understands urls whereas each Weblogic resource has
# different set of elements associated with it. By mapping these resources to 
# urls & operations all kinds of resources can be protected via 
# Oracle Access Manager.
#
# The format of entries is as follows.
# Weblogic Resource Type:Oracle Resource Type: enabled/disabled:
# URL prefix:URL pattern:Operation
# For example <url> : wl_url : enabled : contextPath : uri : httpMethod
# If the resource is configured disabled, the default action can be configured.
# For example disabled,allow
#
# If the operation doesn't come from Weblogic resource field, and is fixed then
# it can be configured by putting the value between <> . For example <execute>
# If the value for operation is not specified then it defaults to "<default>"
#
# Leading & trailing white spaces in the fields and blank lines are allowed.
# Comments can be put by starting the line with #
###############################################################################
##### COMMONLY used resources #####
# HTTP resource. Available keys: application, contextPath, uri, httpMethod, 
# transportType
<url>:wl_url:enabled:contextPath:uri:httpMethod

# ejb - EJB resource. Available keys: application, module, ejb, method, 
# methodInterface, signature
# signature is ignored here for performance reasons. 
# You can include it if you want to.
<ejb>:wl_ejb:enabled:application/module/ejb:methodInterface/method:<execute>

# Web resource. Available keys: application, uri, webResource, httpMethod, 
# transportType
# This resource is deprecated by BEA in WLS 8.1. <url> replaces this resource 
# type. 
# You can enable it if you want to. Refer to WLS 8.1 documentation for details.
<web>::disabled,deny:uri:webResource:httpMethod

# Server resource. Available keys: server, action
# Typically server=<wls server name>
<svr>:wl_svr:enabled:server::action

# Admin resource. Available keys: category, realm, action
# Typically for admin console category=Configuration. realm is ignored in default 
# configuration.
<adm>:wl_adm:enabled:category::action

##### LESS used resources #####

# JDBC resource. Available keys: resourceType, resource, action
#<jdbc>:wl_jdbc:enabled:resourceType:resource:action
<jdbc>::disabled,allow:::
# JMS resource. Available keys: destinationType, resource, action
#<jms>:wl_jms:enabled:destinationType:resource:action
<<jms>::disabled,allow:::
# JNDI resource. Available keys: path, action
#<jndi>:wl_jndi:enabled:path::action
<jndi>::disabled,allow:::

Entering OblixDatabase.isProtected for resource Type=wl_jndi, isEnabled=true, URL=/weblogic/jms/MessageDrivenBeanConnectionFactory, operation=lookup

9.5.9 Preparing the WebLogic Environment

The following procedure describes how to configure the WebLogic environment so that the Security Provider is recognized by the WebLogic Server.

To prepare the environment

1. Copy the mbean jar file from one of the following locations:

   From

   install_dir/oblix/lib/mbeantypes

   to

   WebLogic_Home/server/lib/mbeantypes

   
   

   Note: If you are using WebLogic 8.1, copy wl8NetPointSecurityProviders.jar. If you are using WebLogic 7.0 SP2 and later, copy wl7NetPointSecurityProviders.jar.

   
   

2. Copy the following files from your Security_Provider_install_dir to your WebLogic domain folder:

   NetPointProvidersConfig.properties

   NetPointResourceMap.conf: only for the Application Server domain

3. Ensure that the following Admin credentials are set in clear text in the NetPointProvidersConfig.properties file:

   OB_AdminUserName=admin

   OB_AdminUserCreds=password

   If the NetPointProvidersConfig.properties file has a clear text password, the SSPI reads in the password, encrypts it, and rewrites the properties file with the encrypted password.

   
   

   Note: NetPointProvidersConfig.properties file formatting is lost when Oracle Access Manager rewrites the file with the encrypted password. You may want to save a copy of the NetPointProvidersConfig.properties file. Also, ensure that all parameters are correctly filled as mentioned in "NetPointProvidersConfig.properties".

   
   

   You complete the next step if the SSPI talks to a WebPass that is protected by a WebGate. Otherwise, skip to step 5.

4. WebPass Protected by WebGate: Complete the following activities when the Oracle Access Manager SSPI talks to a WebPass protected by a WebGate:

   1. In the NetPointProvidersConfig.properties file, ensure that OB_WebPassIsProtected is set to true. The OB_CookiePath and OB_CookieDomain parameters are configured correctly.

   2. 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.

      In 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 Administration Guide for details.

      
      

      Note: If you want to set IPValidation to True, configure the IPValidationExceptions parameter to contain the IP address.

      
      

   3. Restart the Web server.

      
      

      Note: Ensure that the security level in this authentication scheme is the same level or a lower level than the one specified in the WebLogic authentication scheme

      
      

      Next, you need to determine if the machine hosting WebPass is running SSL. If it is, complete step 5. Otherwise, skip to step 6.

5. WebPass Host SSL-Enabled: Determine if the machine hosting WebPass is running SSL, and if so, complete the following steps:

   1. Open the NetPointProvidersConfig.properties file and set OB_WebPassSSLEnabled = True.

   2. Obtain the CA certificate from the certificate authority to which the Web server hosting the WebPass or WebGate running in SSL mode has registered, and place it in ca.cer file.

   3. Use the keytool in JAVA_HOME\bin or JAVA_HOME\jre\bin to add the following ca certificate to cacerts keystore present in:

      JAVA_HOME\jre\lib\security folder for weblogic jdk
      keytool -import -alias ca -file ca.cer -keystore JAVA_HOME\jre\lib\
      security\cacerts
      
      

6. Add the following environment variables in the WebLogic Server startup script before the command that starts the server:

   Add the following to the CLASSPATH:

   /install_dir/oblix/lib/wlNetPoint.jar
        /install_dir/oblix/lib/bcprov-jdk14-125.jar
        /install_dir/oblix/lib/xerces.jar
        /install_dir/oblix/lib/jobaccess.jar
   
   

7. Add the following environment variables in the WebLogic Server startup script before the command that starts the server:

   Windows: Add the following to PATH:

   install_dir\oblix\lib
   
   

   Solaris and Linux: Add the following to LD_LIBRARY_PATH:

   install_dir/oblix/lib
   
   

   HP-UX: Add the following to SHLIB_PATH:

   install_dir/oblix/lib
   
   

   Portal Domain: The CLASSPATH and PATH variables should be added just after the SAVE_JAVA_OPTIONS environment variable in the startWebLogic.cmd script (On Unix, it is the startWebLogic.sh script).

8. On Linux, set the LD_ASSUME_KERNEL environment variable to 2.4.19, as follows:

   LD_ASSUME_KERNEL=2.4.19
   export LD_ASSUME_KERNEL
   
   

9. Remove the boot.properties file from the WebLogic domain directory.

   This will cause the startWebLogic script described in the next step to prompt for username and password.

10. In the WebLogic domain directory, edit the appropriate startup script:

    Windows: The script is startWeblogic.cmd

    Unix: The script is startWeblogic.sh

    Ensure the following paths are set in the script:

    /install_dir/oblix/lib/wlNetPoint.jar
         /install_dir/oblix/lib/bcprov-jdk14-125.jar
         /install_dir/oblix/lib/xerces.jar
         /install_dir/oblix/lib/jobaccess.jar
    
    

11. In the WebLogic domain directory, start the WebLogic Server using the appropriate startup script:

    Windows: This command is startWeblogic.cmd

    Unix: This command is startWeblogic.sh

    Using the WebLogic 8.1 Domain Configuration Wizard, you can create instances of a new WebLogic 8.1 domain, for example, mydomain, and a new WebLogic 8.1 server, for example, myserver. You can also create instances of a new WebLogic 8.1.3 Portal domain, for example, portalDomain, and a new WebLogic 8.1.3 portal server, for example, portalServer.

12. Set up a Realm that uses Oracle Access Manager security providers, as follows:

    1. Open a new console window and set the Weblogic environment by executing setEnv.cmd.

       Unix: Source the setEnv.sh script present in the server domain directory.

       Portal Domain: Use the setDomainEnv.cmd script (on Unix it is the setDomainEnv.sh script).

    2. Run the following script and ensure that it has the correct username, password, and URL values:

       Windows: install_dir/setupNetPointRealm.cmd

       Unix: install_dir/setupNetPointRealm.sh

       Portal Domain: Run the script with parameter "portal".

       WLS 7.0: The script does not work and NetPointRealm must be set manually.

    3. Log in to the WebLogic Admin Console, navigate to Domain, Security, Realms and:

       • Verify that NetPointRealm is set as the default.

       • Verify that the security providers are set properly in NetPointRealm.

    4. Script Fails: If the script fails, you must manually add the Oracle Access Manager security realm (NetPointRealm):

       • Go to Domain, Security, Realms and select "Configure a new Realm".

       • For the option "Check Roles and Policies for", ensure that "All Web Applications and EJBs" is selected.

       • Navigate to Providers, Authentication, and configure a new Authenticator and Identity Asserter.

       • Identity Asserter: Select the Token Type ObSSOCookie and in the Details tab, uncheck "Base64Decoding Required".

       • Portal Domain: Set the control flag of Authenticator to OPTIONAL and also configure a Default Authenticator.

       • Navigate to Providers, Authorization and configure a new Authorizer (for the portal domain, only configure a Default Authorizer).

       • Navigate to Providers, Role Mapping and configure a new Role mapper (for the portal domain, only configure a Default Role mapper).

       • Navigate to Providers, Credential Mapping and configure a new Default Credential mapper.

       • Navigate to Domain, Security and select this realm as the default realm.

    You complete step 12 only when configuring a Portal Server domain. Otherwise, skip to step 13.

13. Portal Server Domain: Complete the following steps to configure a Portal Server domain:

    1. Restart the server using the same WebLogic credentials that were used earlier.

    2. In the WebLogic Server Console, navigate to Domain, Security, Realms, NetPointRealm, Providers, Authentication, and:

       • Remove the Default Authenticator.

       • Change the control flag for Authenticator to REQUIRED.

    3. Using the Group Manager, create a group in Oracle Access Manager that maps to the Admin role in the BEA WebLogic Server and contains all the administrators for the BEA Portal.

       For example:

       BEA_Administrators

    4. Create a user (portaladmin) and add it to the BEA_Administrators group; later you login as this user (portaladmin) when restarting the server.

    5. In the WebLogic Server Console Admin Console, navigate to Security, Realms, NetPointRealm and:

       • Click Groups to display all Oracle Access Manager groups.

       • Search for the BEA Admin group that was created in this step. You can use a wild card in the search.

       • Copy the group name.

    6. Click Global Roles, Admin role, Conditions tab and:

       • Add a Role Condition where the caller is a member of the group.

       • Paste in the group name you copied.

    7. Change the role condition from "and" to "or", then click Apply.

    8. Repeat this procedure for the PortalSystemAdministrator role.

       
       

       Note: Other BEA roles can be mapped to Oracle Access Manager groups/users. When you restart the WebLogic Server, it is important that you are logged in as a user in the Oracle Access Manager group associated with the BEA Admin role.

       
       

14. Restart the WebLogic Server.

    The next time you log in to the WebLogic console, provide Master Oracle Access Manager Administrator credentials. You will be authenticated using NetPointRealm.

15. If you are using identity assertion as the authentication mechanism that protects Web applications:

    1. Install a WebGate on the proxy Web server. See "Authentication for Web-Only Resources" for an illustration of this type of installation.

    2. Configure the Oracle Access Manager policies that protect the Web applications to use HTTP as the resource type instead of wl_url.

       
       

       Note: There is one exception to the resource type configuration. The WebLogic administration console always uses form login. The /console policy must use the resource type wl_url.

       
       

16. If anything other than an Oracle Access Manager form-based authentication scheme protects the policies configured with the HTTP resource type, configure a challenge redirect parameter to redirect the user to another Web server that has WebGate installed.

    
    

    Note: If you do not complete this step, the user will have to refresh the browser to access the desired page because the ObSSOCookie set by the WebGate in the HTTP request has not yet been sent to the WebLogic server.

    
    

17. Continue with the following procedures, as needed:

    • "Configuring the Identity Server".

    • "Configuring Multiple WebPass Instances".

9.5.10 Configuring the Identity Server

Next, you complete the following procedure to configure the Identity Server.

To configure the Identity Server

1. Open the oblixappparams.xml file and set the searchstringMinimumLength to zero:

   IdentityServer_install_dir\identity\oblix\apps\common\bin\

   oblixappparams.xml

   <NameValPair ParamName="searchstringMinimumLength" Value="0"/>
   
   

   where IdentityServer_install_dir is the directory where you installed Identity Server.

2. Open the groupservcenterparams.xml file and set the groupMemberSearchStringMinimumLength to zero:

   IdentityServer_install_dir\identity\oblix\apps\groupservcenter\bin\

   groupservcenterparams.xml

   <NameValPair ParamName="groupMemberSearchStringMinimumLength" Value="0"/>
   
   

3. Restart the Identity Server.

   The next step must be completed after Identity System setup.

4. From the Identity System Console, create an administrator with the required View and Delegated Administration rights.

   
   

   Note: This administrator should be the one used for "OB_AdminUserName" parameter in the NetPointProvidersConfig.properties. For more information about configuring administrators, see the Oracle Access Manager Identity and Common Administration Guide.

   
   

9.5.11 Configuring Multiple WebPass Instances

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 the failover purposes.

This section assumes that you have already installed more than one instance of WebPass for the Security Provider. See the Oracle Access Manager Deployment Guide for more information on failover.

To configure multiple WebPass instances

1. Open the NetPointProvidersConfig.properties file in the WebLogic domain directory.

2. Enter the WebPass fully-qualified hostname with the domain name and port number using a comma-separated list.

   For example:

   # 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:

   o foo.domain.com:81

   o bar.domain.com:80

9.6.1 Configuring web.xml to Add Filter-related Nodes

You need to include filter-related nodes at the start of other filter nodes.

To add filter-related nodes

1. Locate the Portal Application's Web module's WEB-INF/web.xml.

2. Add the following filter related nodes at the start of other filter nodes:

   <!-- Login Servlet Filter, required for single sign-on between Portal and Netpoint  -->
      <filter>
            <filter-name>OblixLoginFilter</filter-name>
            <filter-class>ObLoginFilter</filter-class>      
       </filter>
   
   

3. Add the following filter mapping node at the start of other filter mapping nodes:

   <filter-mapping>
         <filter-name>OblixLoginFilter</filter-name>
         <!-- Configure this mapping to invoke the Oblix Login filter  -->
            <url-pattern>/portlets/login_validate/*</url-pattern>
        </filter-mapping>
   

9.6.2 Adding Authentication Methods to web.xml

You may configure different authentication methods in the web.xml (deployment descriptor) of a Web application. The following information explains how you specify the authentication schemes in the <auth-method> tag under <login-config>. The following authentication schemes may be configured:

• Form

• Basic

• CLIENT_CERT

To add form-based authentication to web.xml

1. Add the following to the web.xml file:

   <login-config>
   <auth-method>FORM</auth-method>
   <form-login-config>
   <form-login-page>/login.jsp</form-login-page> -- location of the jsp page that will accept user credentials
   <form-error-page>/fail_login.html</form-error-page> -- location of the page to which request must be redirected upon unsuccessful login 
   </form-login-config>
   </login-config>
   
   

2. Ensure that the login form contains fields for entering username and password, which must be named j_username and j_password, respectively.

3. Ensure that the form posts j_username and j_password values to j_security_check logical name:

   The following example shows how the form should be coded into an HTML page:

   <form method="POST" action="j_security_check">
   <input type="text" name="j_username">
   <input type="password" name="j_password">
   </form>
   

To add basic authentication to web.xml

1. Add the following lines to web.xml:

   <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name> Your_realm_name </realm-name>
   </login-config>
   
   

   where the <auth-method> tag specifies the authentication method (in this case, BASIC), and the <realm-name> tag contains the text that should appear on the dialog box requesting credentials.

2. Save web.xml.

9.6.3 Configuring the login jsp used by the Login Portlet

You need to configure the following in the login jsp used by the login portlet.

To configure the login jsp for the Login Portlets

1. Include following at the start of the login jsp page.

   <%@ page import="com.bea.portlet.PostbackURL,
                   com.bea.netuix.servlets.controls.content.JspContentContext" %>
      <% // Set this url as per your setting %>
         <%@include file="/portlets/NetPointPortalSSO.jsp" %>
   <%
   // Included to get the Base URl for redirection after Authnetication.
   JspContentContext jspContentContext = JspContentContext.getJspContentContext(request);
   PostbackURL url = jspContentContext.getBaseUrl(request, response, "");
   %>
   
   

2. Set the form's action url as following:

   <form method="post" action="/sampleportal/portlets/ login_validate/Oblogin_validate.jsp" type="POST">
   
   

   
   

   Note: The action URL needs to start with the context root included.

   
   

3. Set the user input fields used in login jsp to get the username and password to username and password, respectively.

4. Include a new variable in the login input form:

   <tr>
    <td align="left"> <input type="hidden" name="targeturl" value=<%= url %> > </td>
   </tr>
   
   

5. If your form provides logout functionality, set the logout url to Oblogout.jsp. Else in your logout logic include following code to kill the ObSSOCookie

   <%@ page import="com.oblix.weblogic.configuration.NPConfiguration"%>
   <%@ page import="com.oblix.weblogic.logging.ObDebug"%>
   <%
       // begin block to kill ObSSOCookie
       // Check if the user has ObSSOCookie 
      ObDebug.getInstance().debug("Inside logout.jsp");
       Cookie[] cookies = request.getCookies();
       if ( cookies != null ){
          String obSSOcookie = null;
          for (int i = 0; i < cookies.length; i++) {
      if (cookies[i].getName().equals("ObSSOCookie")) {
      obSSOcookie = cookies[i].getValue();
      // if ObSSOCookie is not null and is not 'loggedout' then 
      // kill it by making it loggedout
   if (obSSOcookie != null && ! obSSOcookie.equals("") && ! obSSOcookie.equals("loggedout")){
    
   Cookie killedSSOCookie = new Cookie("ObSSOCookie", "loggedout");
      String cookieDomain = NPConfiguration.getCookieDomain();
      if(cookieDomain != null && cookieDomain.length() > 0)
      killedSSOCookie.setDomain(cookieDomain);
      killedSSOCookie.setPath("/");
      response.addCookie(killedSSOCookie);
   ObDebug.getInstance().debug("Logout jsp - ObSSOCookie set to loggedout with domain [" + cookieDomain + "]");
      }
      break;
      }
            }
       }
       // end block to kill ObSSOCookie
   %>
   
   

9.6.4 Copying ObLoginFilter.class in the WEB_INF/classes

The ObLoginFilter.class expects that the name of user input fields used in login form are "username" and "password". However, other names can be used.

To use other names

1. Modify the file provided.

2. Compile the file and include it under the WEB-INF/classes folder.

3. Proceed to "Completing Setup".

9.6.5 Completing Setup

Use the following procedure to complete the setup process for this implementation.

In the sampleportal example under the PortalApp application that is shipped as an example with Weblogic 8.1 SP3 we had created a login_validate folder under the portlets folder under the context root and copied Oblogout.jsp and NetpointPortalSSO.jsp just under the portlets folder.