| 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 |
This chapter describes how to use Oracle Access Manager with BEA WebLogic running in a Security Service Provider Interface (SSPI) implementation. WebLogic provides an environment for creating, integrating, securing, and managing distributed Java applications. The Security Provider for WebLogic SSPI (Security Provider) ensures that only appropriate users and groups can access Oracle Access Manager-protected WebLogic resources to perform specific operations. The Security Provider also enables you to configure single sign-on between Oracle Access Manager and WebLogic resources.
This chapter covers the following topics:
Note:
If you are installing the Oracle Access Manager 10.1.4.2 patch release, you must configure the Weblogic Authorization Provider and Adjudication Provider before applying the patch.The Security Provider for WebLogic SSPI provides authentication, authorization, and single sign-on across J2EE applications that are deployed in the BEA WebLogic platform. The Security Provider enables WebLogic administrators to use Oracle Access Manager to control user access to business applications.
The Security Provider provides authentication to BEA WebLogic Portal resources and supports single sign-on between Oracle Access Manager and BEA WebLogic Portal Web applications. Apart from this, the Security Provider also offers user and group management functions.
Note:
The integration with WebLogic supports only one policy domain for each WebLogic server instance. All WebLogic policies must reside in this single policy domain.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 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.
With the Security Provider, you can use Oracle Access Manager to protect WebLogic resources, including Web applications, EJBs, JNDIs, and so on. You can configure single sign-on for Web applications, such that a user who has authenticated to WebLogic can access Oracle Access Manager-protected resources (including WebLogic and non-WebLogic resources) without re-authentication. You can also configure single sign-on such that a user who has authenticated to Oracle Access Manager can access WebLogic resources without re-authentication.
Note:
With the WebLogic Portal, the Security Provider is used only to provide authentication to WebLogic resources. Role Mapping and Authorization are taken care by the Weblogic Portal. Therefore, the Authorizer and Role Mapper must not be configured in NetPointRealm.The following applies only to the WebLogic Server. For Weblogic Portal authentication, see "Authentication for the Portal".
You can use the integration with WebLogic in the following ways:
To provide authentication for mixed Web and non-Web resources:
This scenario assumes that the environment configuration does not use a proxy server running a WebGate. In this scenario, you protect resources in Oracle Access Manager using username and password authentication. This method can be used to protect both HTTP resources on the Web and to protect resources such as EJBs, JNDIs, and other types of applications. In this type of scenario, all J2EE Web application deployment descriptors must be configured to be BASIC or FORM. This method requires use of the Authenticator service provider.
See "Authentication for Mixed Web and Non-Web Resources" for details.
To provide authentication for Web resources only using a proxy server with WebGate installed:
In this scenario, you protect resources using a variety of authentication schemes, such as form, SecurID, and so on. For this type of authentication to work, all J2EE Web applications must have an authen-method deployment descriptor configured to CLIENT-CERT. This configuration uses the Identity Assertion security provider, where authentication is performed based on an external token (in this case, the ObSSOCookie). See "Authentication for Web-Only Resources" for details.
WebGate protects only Web resources (HTTP). When a user attempts access to a Web resource protected by WebGate:
WebGate queries the Access Server, which authenticates and authorizes access to the Web resource.
WebGate sets the ObSSOCookie in the HTTP header.
The Identity Asserter (authentication provider) reads the ObSSOCookie and sets the Subject. The Subject remains until the user session expires. Further authentication is not required to access any type of resource.
Non-Web applications must use the Authenticator service provider rather than the Identity Assertion security provider.c. When Web resource accesses include mixed resources such as JNDI internally, the Authorization Provider handles access decisions.
A WebGate is a Web server plug-in access client that intercepts HTTP requests for Web resources and forwards them to the Access Server for authentication and authorization. An AccessGate is a form of access client that processes requests for Web and non-Web resources (non-HTTP) from users or applications.
With this integration, whether you have Web resources, non-Web resources, or a mix of Web and non-Web resources the question of which component performs authentication is based on the type of deployment. For example:
WebGate comes into play when you have a WebLogic proxy installed and resources deployed on the WebLogic Server are accessed through it.
For non-Web resources, only the Authenticator is involved (the Identity Asserter is not used at all).
When you have a mix of Web and non Web resources, the resource is authenticated by either the Authenticator or the Identity Asserter based upon your deployment descriptor settings
After the user is authenticated a session is created and the Subject is set in the request context. Subsequent access to non-Web resources will not require authentication until the user session expires. For more information on this scenario, see "Authentication for Mixed Web and Non-Web Resources" next.
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.
Process overview: User authentication, mixed resource types
A user attempts to access a Oracle Access Manager-protected WebLogic resource.
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".
The WebLogic Server forwards the username and password to the Security Provider for authentication and authorization.
The Authentication Provider uses the AccessGate to communicate with the Access Server to verify the user's identity.
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.
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.
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.
Note:
When any WebLogic resource is requested, control goes to WebLogic Server and the login page of the application is launched. The Authenticator comes into play only after the login page is submitted. You need to modify JSP only if the ObSSOCookie is set already.For details about the ObSSOCookie, see the Oracle Access Manager Access System Administration Guide.
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.
Process overview: User authentication, Web-only applications
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.
WebGate intercepts the request and queries the Access Server to check if the resource is protected.
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.
The user presents credentials such as user name and password, or a certificate.
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.
The WebLogic proxy plug-in passes the cookie in the HTTP header to the WebLogic Server.
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.
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.
The remaining steps are the same as for "Process overview: User authentication, mixed resource types", step 5 - step 7.
Oracle Access Manager 10g (10.1.4.0.1) supports integration with the WebLogic Portal.
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 Weblogic Portal 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 Weblogic Portal, 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".
Process overview: User authentication for the Portal
A user attempts to access a WebLogic resource that is protected by Oracle Access Manager.
The WebLogic Server challenges the user for username and password.
The WebLogic Server forwards the username and password to the Security Provider for authentication.
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.
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 WebLogic Portal".
Process overview: Single sign-on between Oracle Access Manager-protected non-WebLogic resources to WebLogic resources
A user accesses Oracle Access Manager-protected non-WebLogic resources and the ObSSOCookie is set.
A user accesses a WebLogic resource.
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.
WebLogic authorizes the resources in the Portal Application.
Process overview: Single sign-on between WebLogic resources to Oracle Access Manager-protected non-WebLogic resources
A user tries to access a WebLogic resource.
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.
The user enters their credentials in the login form; the credentials get posted to a Login Filter (ObLoginFilter configured in web.xml).
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.
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.
The user accesses Oracle Access Manager-protected non-WebLogic resources with the ObSSOCookie set and no re-authentication performed.
Any references to specific versions and platforms in this chapter are made 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.
Information about installing and configuring the components required for integration of Oracle Access Manager and WebLogic is provided in the following sections of this chapter and in a readme file. For access to the readme, go to:
Security_Provider_install_dir
where Security_Provider_install_dir is the directory where the where the Security Provider for WebLogic SSPI is installed.
The following sections provide the information needed to install and configure the Security Provider.
Tip:
For information on upgrading this integration, see the Oracle Access Manager Upgrade Guide.Task overview: Installing and configuring the Security Provider
Before you install Security Provider for WebLogic, you must complete various tasks.
See "Preparing the Environment" for details.
Perform the installation procedure, depending on the platform where you are installing Oracle Access Manager.
You perform a typical installation to supply default values for the Security Provider configuration. You perform advanced installation to override the default configuration.
See "Installing the Security Provider", "Completing a Typical Installation", and "Completing Advanced Installation" for details.
After installing Oracle Access Manager and WebLogic, you define Oracle Access Manager policy domains that provide a method for protecting WebLogic applications.
See "Setting Up WebLogic Policies in Oracle Access Manager" for details.
After you have created your resource types and authentication schemes, you can run the NetPoint Policy Deployer, or you can configure the policies manually in Oracle Access Manager.
See "Running the NetPoint Policy Deployer" or "Manually Configuring WebLogic Policies in Oracle Access Manager" for details.
Configure the NetPointResourceMap.conf file to create mappings of WebLogic resources to Oracle Access Manager resources.
See "Mapping WebLogic Resources to Oracle Access Manager Resources" for details.
Configure the WebLogic environment so that the Security Provider is recognized by the WebLogic Server.
See "Preparing the WebLogic Environment" for details.
Configure the Identity Server.
See "Configuring the Identity Server" for details.
Configure multiple WebPass instances for failover purposes.
See "Configuring Multiple WebPass Instances" for details.
Before you install Security Provider for WebLogic, you must complete the following tasks:
Task overview: Before installing the Security Provider for WebLogic
Install and set up the WebLogic Portal and WebLogic Server as described in your vendor documentation.
Note:
Oracle Access Manager supports integration with the WebLogic Portal.Be sure you are using JDK 1.4.
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.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 System Administration Guide for details.
Install Security Provider as described in "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
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 System Administration Guide for information on AccessGates and the configureAccessGate tool.
On the Welcome screen, click Next.
Confirm that you are logged in as a user with administrative rights, then click Next.
Select an installation directory and click Next.
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.
Select Typical or Advanced and click Next.
Continue with the procedure that is appropriate for your environment:
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
Complete the WebPass details, as follows:
Enter the hostname where webpass is installed.
Enter the webpass port number.
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.
WebPass Protected by WebGate: Complete the following steps.
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 (/).
Complete directory-specific information, as follows:
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.
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.
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.
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.
Supply information regarding the AccessGate and Access Server that you have installed.
Review the readme that appears.
The information in this readme is covered in this chapter also.
Confirm the installation.
Continue with "Setting Up WebLogic Policies in Oracle Access Manager".
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.
Note:
Do not attempt an advanced installation unless you are familiar with creating policy domains and policies in Oracle Access Manager and have run though at least one typical installation of the Security Provider.To finish an advanced installation
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.
Complete the screen subtitled "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.
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.
Finish the installation by completing the steps described in "Completing a Typical Installation".
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 System Administration Guide provides details on tasks described in the following sections.
Note:
The resource type wl_svr described in this document is available if you want to protect access to starting and stopping the WebLogic server. To do this, you can define a policy (as described in "To create policies for the domain") that uses this resource type. You can find the information you need for this policy in the isAccessAllowed entries in the debug logs that contain the string <svr>. Note that you must create this policy manually. The deployment tool provided with the Oracle Access Manager Security Provider does not create this policy for you. Also, the resource type wl_ejb is used when you deploy EJB applications. You can create policies that use this type of resource manually, or you can use the deployer tool to create these policies.To configure the WebLogic resource types
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.
From the List All Resource Types page, click Add.
The Define a new Resource Type page appears.
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
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
Define and save the third resource type:
Third resource:
Name: wl_adm
Display name: wl_adm
Resource matching: case insensitive
Resource operation: DEFAULT
Define and save the fourth resource type:
Name: wl_ejb
Display name: wl_ejb
Resource matching: case insensitive
Resource operation: EXECUTE
Define and save the fifth resource type:
Name: wl_authen
Display name: wl_authen
Resource matching: case insensitive
Resource operation: LOGIN
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
From the Access System Console, click Access System Configuration, Authentication Management, Add.
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).
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.Save the information on the General tab by clicking Save.
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.
After creating a plug-in, you can enable the authentication scheme by clicking the General tab, Modify, selecting the Enable option, and clicking Save.
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.
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.
Continue with one of the following discussions:
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:
Note:
If you do not want to use the Policy Deployer tool, you must manually configure WebLogic policies as described in "Manually Configuring WebLogic Policies in Oracle Access Manager".To prepare for running the Policy Deployer Tool
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
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.
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
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).
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.
From the command line, enter the following:
java com.oblix.weblogic.tools.NetPointPolicyDeployer userid password
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.
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.
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 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".Ensure that the policy domain that was just created is enabled in Oracle Access Manager.
In the Policy Manager, click My Policy Domains, then click the WebLogic policy domain.
The status of the policy domain should be enabled.
If the status of the policy domain is not enabled, click Modify and enable it.
To run the Policy Deployer after the first time
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.
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.
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=trueThis 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.
Follow step 2 - step 5 of "To run the Policy Deployer Tool for the first time".
Continue with "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
Create a WebLogic policy domain, as described in "To create a policy domain in Oracle Access Manager" .
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.
Add authorization and authentication rules to the domain, as described in "To add authorization and authentication rules to the domain".
Define policies within the domain, as described in "To create policies for the domain".
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
Log in to the Access System.
From the Policy Manager, click Create Policy Domain.
Define the following policy domain:
Name: SecuProvForWebLogic
Description: Policy domain for WebLogic resources.
Save this policy domain.
To add resources to the domain in Oracle Access Manager
From the Policy Manager, click My Policy domains and select the new policy domain.
Click the Resources tab for the policy domain.
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".
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.
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.
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.
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
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.
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.
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
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.
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.Create a default authorization rule that allows anonymous access, as follows:
Click the Default Rules tab, Authorization Rules, Add.
Select the rule for anonymous access that you created in the previous step.
This is the rule called Authz rule for anyone.
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.
Create a default rule that authenticates users for access to all resources that do not fall under a specific policy, as follows:
Click the Default Rules tab, Authentication Rule, Add.
The General page appears.
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
Create policies for this domain from the Policy Manager. For example:
Policy Manager, policy_domain, Policies tab
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
Resource: /Authen/Basic
Authentication Rule tab:
Name: Basic authentication rule
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.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" .
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".
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".
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 System Administration Guide.
Continue with "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.
Note:
The NetPointResourceMap.conf file is used only for the WebLogic Server integration, not for WebLogic Portal integrationAfter 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
Locate the NetPointResourceMap.conf file. in the directory where the Security Provider is installed.
Review the format of this file in "NetPointResourceMap.conf File Format" .
Edit the file using information on Oracle Access Manager resource type definitions in "Setting Up WebLogic Policies in Oracle Access Manager".
Continue with "Preparing the WebLogic Environment".
Resources that have mapping entries in this file are the only ones protected. Resources that do not have a mapping entry in this file are allowed access by default.
The format of entries in the NetPointResourceMap.conf file is as follows:
Weblogic Resource Type:Oracle Access Manager Resource Type: enabled|disabled:URL prefix:URL pattern:Operation
where:
Weblogic Resource Type: The WebLogic resource type. For example: <url>.
Oracle Access Manager Resource Type: The Oracle Access Manager resource type that is mapped to the WebLogic resource type. For example: wl_url.
enabled|disabled: If enabled, all resources of the specified WebLogic resource type are protected by Oracle Access Manager. If disabled:
All users can access the resource if the status is disabled, allow.
No users can access the resource if the status is disabled, deny.
URL prefix: The WebLogic elements that form a Oracle Access Manager URL prefix under which all resources are protected. This URL prefix is specified in a Oracle Access Manager policy. Each element in the URL prefix is a type of resource. For example, the following URL prefix can be used for EJBs:
application/module/ejb
where application and module are a specific WebLogic application and module.
URL pattern: The WebLogic elements that form a more granular Oracle Access Manager URL pattern than is specified by a URL prefix. This pattern is specified in an Oracle Access Manager policy. For example, to control access to users based on a particular method, you would specify:
methodInterface/method
Operation: This maps to a WebLogic resource element such as HTTPMETHOD. If you specify a value in angle brackets ("<>"), the policy returns the matching string. If you omit the brackets, the policy returns the value associated with the parameter.
This example lists the content of the NetPointResourcemap.conf file
############################################################################### # 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:::
Note:
JNDI, JDBC, JMS resource protection is disabled by default. These can be enabled in NetPointResourceMap.conf.The tool can be used to create policies automatically only for Web and ejb resources. It cannot be used for JNDI, JDBC, JMS, and other types of resources. These need to be created by hand in the Access System Console. To find the URL pattern and operation used for the policy, set the log level to debug for the WebLogic SSPI package and look into the logs for the string "Entering OblixDatabase.isProtected for". For example:
Entering OblixDatabase.isProtected for resource Type=wl_jndi, isEnabled=true, URL=/weblogic/jms/MessageDrivenBeanConnectionFactory, operation=lookup
For this example, a resource type wl_jndi needs to be first created in Access System Console with a resource operation of "lookup". Then policy needs to be created for the url /weblogic/jms/MessageDrivenBeanConnectionFactory (or parts of it such as /weblogic/jms) in the weblogic policy domain. For more information about protecting resources, see the Oracle Access Manager Access System Administration Guide.
The following procedure describes how to configure the WebLogic environment so that the Security Provider is recognized by the WebLogic Server.
Note:
When you deploy an application on Weblogic 9.2, be sure that you deploy it with the appropriate deployment descriptors for Web applications. The deployment descriptors for Web applications are web.xml and weblogic.xml. Also be sure to deploy the application with deployment descriptors for EJB applications. The files ejb-jar.xml and weblogic-ejb-jar.xml are the deployment descriptors for EJB applications.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 9.2, copywl8NetPointSecurityProviders_Upgraded.jar. If you are using WebLogic 8.1, copy wl8NetPointSecurityProviders.jar. If you are using WebLogic 7.0 SP2 and later, copy wl7NetPointSecurityProviders.jar.Copy the following files from your Security_Provider_install_dir to your WebLogic domain folder:
NetPointProvidersConfig.properties
NetPointResourceMap.conf: only for the WebLogic Server domain
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.
WebPass Protected by WebGate: Complete the following activities when the Oracle Access Manager SSPI talks to a WebPass protected by a WebGate:
In the NetPointProvidersConfig.properties file, ensure that OB_WebPassIsProtected is set to true. The OB_CookiePath and OB_CookieDomain parameters are configured correctly.
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 System Administration Guide for details.
Note:
If you want to set IPValidation to True, configure the IPValidationExceptions parameter to contain the IP address.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 schemeNext, you need to determine if the machine hosting WebPass is running SSL. If it is, complete step 5. Otherwise, skip to step 6.
WebPass Host SSL-Enabled: Determine if the machine hosting WebPass is running SSL, and if so, complete the following steps:
Open the NetPointProvidersConfig.properties file and set OB_WebPassSSLEnabled = True.
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.
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
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
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).
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
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.
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
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, for example, portalServer.
Set up a Realm that uses Oracle Access Manager security providers, as follows:
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).
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
Note:
To use policies based on roles for Web and EJB applications in WebLogic SSPI, run thesetupNetPointRealm tool with the sspi_role parameter.
For example:
Install_dir\setupNetPointRealm.cmd sspi_role
Portal Domain: Run the script with parameter "portal".
WebLogic Server 7.0: The script does not work and NetPointRealm must be set manually.
WebLogic Server 9.2 on Unix: Set the domName variable in the install_dir/setupNetPointRealm.properties file. Then run the Install_dir/setupNetPointRealm_wl92.sh script.
For WebLogic 9.2, do the following:
For the portal server, verify that both the Weblogic Default and Oblix Authentication provider are configured.Change the control flag for Oblix authentication provider to OPTIONAL, and verify that the control flag for the Weblogic authentication provider is REQUIRED.
Log in to the WebLogic Admin Console, navigate to Domain, Security, Realms and do the following:
Verify that NetPointRealm is set as the default.
Verify that the security providers are set properly in NetPointRealm.
Use the following steps for WebLogic Server 9.2:
Click Lock and Edit in the WebLogic Admin Console.
Navigate to NetpointRealm, Providers, Certification Path, WebLogicCertPathProvider. Select the Current Builder option to use the WebLogicCertPathProvider as the current builder. Click Activate Changes to activate all changes.
Set NetPointRealm as the default realm.
In the left pane, select your domain to open the Settings page for your domain. Click the Security tab. Click General. Select NetPointRealm as the default security realm. Click Save. Click Activate Changes to activate all changes.
If the 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).
For role based policies, you also need to configure a Default Authorization Provider. Navigate to Providers, Authorization and configure a Default Authorization Provider.
For role based policies, navigate to Providers, Adjudication and configure a new Adjudication Provider.
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.
Portal Server Domain: Complete the following steps to configure a WebLogic Portal domain:
Restart the server using the same WebLogic credentials that were used earlier.
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.
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
Create a user (portaladmin) and add it to the BEA_Administrators group; later you login as this user (portaladmin) when restarting the server.
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.
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.
Change the role condition from "and" to "or", then click Apply.
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.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.
If you are using identity assertion as the authentication mechanism that protects Web applications:
Install a WebGate on the proxy Web server. See "Authentication for Web-Only Resources" for an illustration of this type of installation.
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.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.Continue with the following procedures, as needed:
Next, you complete the following procedure to configure the Identity Server.
To configure the Identity Server
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.
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"/>
Restart the Identity Server.
The next step must be completed after Identity System setup.
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.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 for the Security Provider. See the Oracle Access Manager Deployment Guide for more information on failover.
To configure multiple WebPass instances
Open the NetPointProvidersConfig.properties file in the WebLogic domain directory.
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
The Security Provider for WebLogic SSPI now supports WebLogic role names as policy names. Roles defined for your Web and EJB applications deployed in WebLogic can be mapped to policies in Oracle Access Manager.
Before you can create create policies in Oracle Access Manager that are based on WebLogic roles, you need to set obRoles.useRoleBasedPolicies=true in the NetPointProvidersConfig.properties file.
You can use the following methods to create role based policies in Oracle Access Manager:
The NetPoint Policy Deployer tool creates the policies in Policy Manager. See "Running the NetPoint Policy Deployer" for details on running the NetPoint Policy Deployer tool.
Example 10-1 shows the resource, authorization rule, and policy created for a Web application deployed on WebLogic.
Example 10-1 Oracle Access Manager Policy Based on WebLogic Role
The following shows an excerpt from the deployment descriptor (web.xml file) used by a Web application deployed on WebLogic:
<security-role>
<description>
Broker
</description>
<role-name>
Broker
</role-name>
</security-role>
Logical roles in the web.xml file are mapped to physical groups or users in the weblogic.xml file. The following code shows the corresponding weblogic.xml file excerpt:
<security-role-assignment>
<role-name>Broker</role-name>
<principal-name>BrokerGroup</principal-name>
</security-role-assignment>
After running the NetPoint Policy Deployer tool, the following resource, authorization rule, and policy are created for the application in Policy Manager:
Resource name: /BrokerGroup
Resource Details:
Resource type: J2EE_Role
URL prefix: /BrokerGroup
Description: Resource used by the role /BrokerGroup
Authorization Rule Name: Authorization rule for BrokerGroup
Authorization Rule Details:
General tab:
Name: Authorization rule for /BrokerGroup
Description: Authorization rule for role /BrokerGroup
Enabled: Yes
Actions tab: Leave blank.
Allow Access tab: user1k2
Deny Access tab: user1k3
Policy Name: Policy for BrokerGroup
Policy Details:
General tab:
Name: Policy for J2EE_Role /BrokerGroup
Description: Policy for J2EE_Role /BrokerGroup
Resource Type: J2EE_Role
Resource Operation: IN
Resource:/BrokerGroup
Authentication Rules tab:
Name: Use Default
Authorization Expression tab: Authorization Rule for / BrokerGroup
If you do not wish to use the Policy Deployer tool, of if you run into errors, you can manually configure the role based policies in Oracle Access Manager. The following steps discuss the operations that you need to perform:
Configuring a New J2EE_Role Resource Type and Operation
Use the following steps to configure a new J2EE_Role resource type and operation:
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.
From the List All Resource Types page, click Add.
The Define a New Resource Type page appears.
Define and save the new resource type. For example:
Resource Name: J2EE_Role1
Display Name: J2EE_Role1
Resource matching: Case Insensitive
Resource operation: IN
Note:
You can assign any name to theJ2EE_Role resource type. You should use the same value for the ObRoles.J2EEResourceType parameter in the NetPointProvidersConfig.properties file.Adding Resources to the Policy Domain
Next, you need to add resources to the policy domain for WebLogic. Add the resource for user authentication. Also add resources corresponding to the Admin, Operator, Deployer, and Monitor roles in WebLogic. You would also need to add resources corresponding to roles defined in the deployment descriptors of Web applications deployed in WebLogic. Use the following steps to add the resources:
From the Policy Manager, click My Policy Domains and select the WebLogic (SecuProvForWeblogic) policy domain.
Click the Resources tab for the policy domain.
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".
Click Add, then configure, and save the resource for role Admin:
Resource type: J2EE_Role1
URL prefix: /Admin
Description: Resource used by the role Admin
Click Add, then configure, and save the resource for role Operator:
Resource type: J2EE_Role1
URL prefix: /Operator
Description: Resource used by the role Operator
Click Add, then configure, and save the resource for role Deployer:
Resource type: J2EE_Role1
URL prefix: /Deployer
Description: Resource used by the role Deployer
Click Add, then configure, and save the resource for role Monitor:
Resource type: J2EE_Role1
URL prefix: /Monitor
Description: Resource used by the role Monitor
Repeat the preceding step for any application role defined in WebLogic.
For example, if an application defines the Broker role in its web.xml file and the Broker role is mapped to the principal BrokerGroup in the weblogic.xml file, then you would need to perform the following step:
Click Add, then configure, and save the resource for role BrokerGroup:
Resource type: J2EE_Role1
URL prefix: /BrokerGroup
Description: Resource used by the role BrokerGroup
Adding Authorization Rules to the Policy Domain
Next, you need to add authorization rules to the policy domain for WebLogic. Use the following steps to add authorization rules:
From the Policy Manager, click My Policy Domains and select the WebLogic (SecuProvForWeblogic) policy domain name.
Click the Authorization Rules tab for the policy domain.
Click Add, and create the authorization rule for the Admin role. For example:
General tab:
Name: Authorization rule for Admin
Description: Authorization rule for role Admin
Enabled: Yes
Actions tab: Leave blank.
Allow Access tab: Add users whom you want to allow access.
Deny Access tab: Add users whom you want to deny access.
Click Add, and create the authorization rule for the Deployer role. For example:
General tab:
Name: Authorization rule for Deployer
Description: Authorization rule for role Deployer
Enabled: Yes
Actions tab: Leave blank
Allow Access tab: Add users whom you want to allow access.
Deny Access tab: Add users whom you want to deny access.
Click Add, and create the authorization rule for the Operator role. For example:
General tab:
Name: Authorization rule for Operator
Description: Authorization rule for role Operator
Enabled: Yes
Actions tab: Leave blank.
Allow Access tab: Add users whom you want to allow access
Deny Access tab: Add users whom you want to deny access
Click Add, and create the authorization rule for the Monitor role. For example:
General tab:
Name: Authorization rule for Monitor
Description: Authorization rule for role Monitor
Enabled: Yes
Actions tab: Leave blank.
Allow Access tab: Add users whom you want to allow access
Deny Access tab: Add users whom you want to deny access
Repeat the preceding step for any application role defined in WebLogic.
For example, if an application defines the Broker role in its web.xml file and Broker role is mapped to the principal BrokerGroup in the weblogic.xml file, then you must perform the following step:
Click Add, and create the authorization rule for the BrokerGroup role. For example:
General tab:
Name: Authorization rule for BrokerGroup
Description: Authorization rule for role BrokerGroup
Enabled: Yes
Actions tab: Leave blank.
Allow Access tab: Add users whom you want to allow access
Deny Access tab: Add users whom you want to deny access
Creating Role Based Policies for the Domain
The next step is to create the role based policies for the domain. Use the following steps to add policies:
From the Policy Manager, click My Policy Domains and select the WebLogic (SecuProvForWeblogic) policy domain name.
Click the Policies tab for the policy domain.
Click Add, and add the basic authentication policy. For example:
General tab:
Name: Basic authentication policy
Description: Authentication using basic LDAP username and password
Resource Type: wl_authen
Resource Operation: LOGIN
Resource:/Authen/Basic
Authentication Rules tab:
Name: Basic authentication rule
Scheme: Select the basic authentication scheme, NetPoint WebLogic BasicOver LDAP
Authorization Expression tab: Add the rule, Authz Rule for Authen
Click Add, and add the policy for the Admin role. For example:
General tab:
Name: Policy for J2EE_Role Admin
Description: Policy for J2EE_Role Admin
Resource Type: J2EE_Role1
Resource Operation: IN
Resource:/Admin
Authentication Rules tab:
Name: Use Default
Authorization Expression tab: Authorization Rule for Admin
Click Add, and add the policy for the Deployer role. For example:
General tab:
Name: Policy for J2EE_Role Deployer
Description: Policy for J2EE_Role Deployer
Resource Type: J2EE_Role1
Resource Operation: IN
Resource:/Deployer
Authentication Rules tab:
Name: Use Default
Authorization Expression tab: Authorization Rule for Deployer
Click Add, and add the policy for the Operator role. For example:
General tab:
Name: Policy for J2EE_Role Operator
Description: Policy for J2EE_Role Operator
Resource Type: J2EE_Role1
Resource Operation: IN
Resource:/Operator
Authentication Rules tab:
Name: Use Default
Authorization Expression tab: Authorization Rule for Operator
Click Add, and add the policy for the Monitor role. For example:
General tab:
Name: Policy for J2EE_Role Monitor
Description: Policy for J2EE_Role Monitor
Resource Type: J2EE_Role1
Resource Operation: IN
Resource:/Monitor
Authentication Rules tab:
Name: Use Default
Authorization Expression tab: Authorization Rule for Monitor
Repeat the preceding step for any application role defined in WebLogic.
For example, if an application defines the Broker role in its web.xml file and Broker role is mapped to principal BrokerGroup in weblogic.xml, then you would need to use the following step:
Click Add, and add the policy for the BrokerGroup role. For example:
General tab:
Name: Policy for J2EE_Role BrokerGroup
Description: Policy for J2EE_Role BrokerGroup
Resource Type: J2EE_Role1
Resource Operation: IN
Resource:/Monitor
Authentication Rules tab:
Name: Use Default
Authorization Expression tab: Authorization Rule for BrokerGroup
Oracle Access Manager supports integration with the WebLogic Portal.
To enable single sign-on between Portal Web Applications and Oracle Access Manager protected resources, the Portal Web Application must be set up for ObSSOCookie handling. The prerequisite to support single sign-on for the Portal Web Application is that it should be using a form-based login portlet for authentication. The "sampleportal" Web Application module a part of "portalApp" Web Application, which is shipped with Weblogic Portal 8.1.3 and is considered as an example.
Following is an outline of the procedures you need to complete to set up single sign-on for the Portal Web Application module.
Task overview: Configuring single sign-on for the WebLogic Portal
Edit the web.xml file, as described in "Configuring web.xml to Add Filter-related Nodes".
Configure the login jsp, as described in "Configuring the login or groupspace jsp used by the Login Portlet".
Copy the login filter class, as described in "Copying ObLoginFilter.class in the WEB_INF/classes".
Finish setup, as described in "Completing Setup".
Test your configuration, as described in "Testing Single Sign-On for the WebLogic Portal".
You need to include filter-related nodes at the start of other filter nodes.
Note:
The mapping mentioned in the filter and the POST action URL set in the form should be the same. The only difference is that the action URL will include the context root too and the Oblogin_validate.jsp name will be present.To add filter-related nodes in WebLogic's web.xml file
Locate the Portal Application's Web module's WEB-INF/web.xml.
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>
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>
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 WebLogic's web.xml file
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>
Ensure that the login form contains fields for entering username and password, which must be named j_username and j_password, respectively.
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 WebLogic's web.xml file
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.
Save web.xml.
For WebLogic 8.1, you must configure the following in the login.jsp that is used by the login portlet. For WebLogic 9.2, you configure the groupspace.jsp that is used by the login portlet.
To configure the login or groupspace jsp for the Login Portlets
For WebLogic 9.2, include the following at the start of the groupspace.jsp:
<%@ 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.
PostbackURL url=PostbackURL.createPostbackURL(request,response);
%>
For WebLogic 8.1, set the form's action URL as follows:
<form method="post" action="/sampleportal/portlets/ login_validate/Oblogin_validate.jsp" type="POST">
For WebLogic 9.2, set the form's action URL as follows:
<form method="post" action="/groupspace/portlets/login_validate/Oblogin_validate.jsp" tyle="margin:0px; padding: 0px;">
For WebLogic 8.1, include following at the start of the login jsp:
<%@ 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, "");
%>
For WebLogic 8.1, 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.Set the user input fields used in login jsp to get the username and password to username and password, respectively.
Include a new variable in the login input form:
<tr> <td align="left"> <input type="hidden" name="targeturl" value=<%= url %> > </td> </tr>
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
%>
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.
Modify the file provided.
Compile the file and include it under the WEB-INF/classes folder.
Proceed to "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, Oracle provides a login_validate folder under the portlets folder in the context root. The files Oblogout.jsp and NetpointPortalSSO.jsp are located under the portlets folder. These files are included in the installation directory as follows:
oblix/examples/src/webapp/portalApp/sampleportal
Except for Oblogout.jsp, Oblogin_validate.jsp and NetPointPortalSSO.jsp, you must configure the jsp files for each application.
For WebLogic 9.2, in the context root, portlets folder, Oracle provides a login_validate folder. The files Oblogout.jsp and NetpointPortalSSO.jsp are locaetd under the context root. These files are located in the installation directory as follows:
oblix/examples/src/webapp/portalApp/sampleportal/Oblogin_validate.jsp
oblix/examples/src/webapp/portalApp/sampleportal/Oblogout.jsp
oblix/examples/src/webapp/portalApp/sampleportal/ObloginFilter.class
oblix/examples/src/webapp/portalApp/groupspace/groupspace.jsp
oblix/examples/src/webapp/portalApp/groupspace/NetpointPortalSSO.jsp
oblix/examples/src/webapp/portalApp/groupspace/web.xml
Copy Oblogout.jsp under context root of the application.
Copy NetpointPortalSSO.jsp under context root of the application.
Under context root of your application module, create a folder "login_validate" and copy the Oblogin_validate.jsp.
This file's contents is displayed only when the filter is not invoked.
Continue with "Testing Single Sign-On for the WebLogic Portal".
You can test the examples provided in the following directory:
Security_Provider_install_dir/examples
These samples allow you to test single sign-on for Web applications and EJBs either using or not using identity assertion for authentication.
There are readmes in the example directories. These readmes provide instructions for testing different types of resources.
For the WebLogic Portal: The examples\src\webapp\portalApp\sampleportal does not contain a full sample that can be deployed.
To test single sign-on for the WebLogic Portal
Configure the WebLogic_install_dir\samples\domains\portal domain to use the Oracle Access Manager Security Provider.
Locate the deployed sampleportal example for WebLogic 8.1 as follows:
WebLogic_install_dir\samples\portal\portalApp\sampleportal
Locate the deployed sampleportal example for WebLogic 9.2 as follows:
WebLogic_install_dir\samples\portal\portalApp
Copy and replace the following files:
For WebLogic 8.1, copy and replace from:
Security_Provider_install_dir\examples\src\webapp\portalApp\ sampleportal
To:
WebLogic_install_dir\samples\portal\portalApp\sampleportal
Replace the files as indicated in Table 10-1:
Table 10-1 Files To Be Replaced for WebLogic 8.1
| New file (in the Oracle Access Manager installation directory) | File to be replaced |
|---|---|
|
login.jsp |
\portlets\login.jsp |
|
NetpointPortalSSO.jsp |
\portlets\NetpointPortal.jsp |
|
Oblogout.jsp |
\portlets\Oblogout.jsp |
|
web.xml |
\WEB-INF\web.xml |
|
ObLoginFilter.class |
\WEB-INF\classes\ObLoginFilter.class |
|
Oblogin_validate.jsp |
\portlets\login_validate\Oblogin_validate.jsp |
For WebLogic 9.2, copy and replace from:
Deployment path: Weblogic_install_dir/weblogic92/samples/portal/portalApp
To the following :
Library path: Domain_dir//servers/AdminServer/tmp/_WL_user/ wlp-groupspace-web-lib/6nsdg
Replace the files as indicated in Table 10-2:
Table 10-2 Files To Be Replaced for WebLogic 9.2
| New file (in the Oracle Access Manager installation directory) | File to be replaced |
|---|---|
|
oblix/examples/src/webapp/portalApp/ groupspace/groupspace.jsp |
library path/groupspace.jsp |
|
oblix/examples/src/webapp/portalApp/ groupspace/NetpointPortalSSO.jsp |
library path/NetpointPortalSSO.jsp |
|
oblix/examples/src/webapp/portalApp/ sampleportal/Oblogout.jsp |
library path/Oblogout.jsp |
|
oblix/examples/src/webapp/portalApp/ sampleportal/ObLoginFilter.class |
library path/WEB_INF/classes/ObloginFilter.class |
|
oblix/examples/src/webapp/portalApp/ groupspace/Web.xml |
library path/WEB_INF/web.xml |
|
oblix/examples/src/webapp/portalApp/ sampleportal/oblogin_validate.jsp |
library path/portlets/login_validate/ Oblogin_validate.jsp |
Either restart the WebLogic Portal or redeploy the PortalApp example.
You can configure the Security Provider for WebLogic to perform an authorization in which the authorization scheme uses external data that resides in the HTTP servlet request for Web applications to determine if a user is allowed access. For example, the authorization scheme can determine that a request must come from a particular IP address, such as the user's home or work machine. The access decision can be based on other factors such as rules. For example, you can allow access only if the user belongs to the Engineering role.
See the Oracle Access Manager Access System Administration Guide and the Oracle Access Manager Developer Guidefor details on authorization schemes that use external data.
Information from a user's role and the ContextHandler is sent to the Access Server based on the configuration of a custom authorization scheme. The ContextHandler is an object that WebLogic passes to the SSPI. The Access Server passes this information to a custom authorization plug-in that makes the authorization decision. It supports three formats for the user parameter field in the authorization scheme definition:
RA_roles: Roles that the user belongs to appear as a comma-separated string.
RA_http.method: This executes the method on an HTTPServletRequest object and returns a string value. For example, RA_http.getRemoteAddr() gets the IP address of the machine where the user sent the request.
RA_http.session.method: This executes the method on an HTTPSession object and returns string values. For example, RA_http.session.getAttribute(myattribute) gets the value of the session attribute named myattribute and returns it as a string. For example, if you want to provide a coupon to a user who has $1,000 of purchases in a shopping cart, you can detect the spending level on a session attribute.
Context-sensitive authorization can be done for EJBs based on the method parameter values apart from the roles. This is done using the reverse action functionality provided by the Access Server. A custom authorization scheme is required for this purpose. You can demonstrate this for a stateless EJB using the following procedure, which limits access to the buy method for the BEAS stock only.
Copy the shared library req_context, as follows:
From: install_dir/examples/src/webapp/contextAuthz
To: Access Server host, AccessServer_install_dir/oblix/lib
Navigate to the Access System Console, Access System Configuration, Authorization Management, then click the Add button.
In the Shared Library field, enter the path to the req_context.
For example:
c:\OracleAccessManager\access\oblix\lib\req_context
In the User Parameter field, add RA_ejb.Parameter1.
In the Required Parameter field, add the following name value pair.
paramName_1 ejb.Parameter1 paramValue_1 BEAS
Saving the scheme, then restart the Access Server.
Create an authorization definition using this authorization scheme in the domain used for SSPI.
Modify the policy for the EJB buy method by setting the authorization rule to the authorization definition that you created in the previous step.
Run the EJB client.
You should get the following output, where the buy of BEAS shares goes successful but the buy of MSFT shares fail due to access control.
run:
[java]
[java] Beginning statelessSession.Client...
[java]
[java] user: admin
[java] Creating a trader
[java] Buying 100 shares of BEAS.
[java] Buying 200 shares of MSFT.
[java] There was an exception while creating and using the Trader.
[java] This indicates that there was a problem communicating with the server: java.rmi.AccessException:
[EJB:010160]Security Violation: User: 'admin' has insufficient permission to access EJB: type=<ejb>,
application=_appsdir_ejb20_basic_statelessSession_ear, module=ejb20_basic_statelessSession.jar, ejb=statelessSession,
method=buy, methodInterface=Remote, signature={java.lang.String,int}.
[java]
[java] End statelessSession.Client...
[java]
A custom plug-in similar to this can be written in C to implement the business logic according to your needs.
There is an example of context-specific authorization provided with the security Web application sample in the installation directory. Details for how to configure the authorization scheme is provided in the readme.
To enable auditing, you need to add an auditing provider in the WebLogic security realm. There is a default provider installed when you install WebLogic.
The default auditing provider writes the audit records to the following file:
WebLogic_domain_directory/server/DefaultAuditRecorder.log
where WebLogic_domain_directory is the name of the WebLogic domain and server is the server name.
WebLogic audits all authentication and authorization successes and failures. The Security Provider for WebLogic audits the reason for any failures. The failure logs appear before the WebLogic failure log.
WebLogic writes debug logs to the following files:
WebLogic_domain_director/server/server.log
Where WebLogic_domain_directory is the name of the WebLogic domain and server is the server name.
For debugging, set the configuration parameter ObDebugMode=true in the NetPointProvidersConfig.properties file. See "NetPointProvidersConfig.properties" for details. The change is takes effect after 60 seconds. Debug logs are written to the server.log file. You can also configure debug logs to print to stdout from the WebLogic administration console.
For more information about a log from the catalog, use WebLogic's CatInfo utility. Set the WebLogic environment by running the setdomainEnv.cmd (or .sh for Unix), and then run:
java weblogic.i18ntools.CatInfo -id message ID
This command also lists the cause action details for the log message.
The SSPI uses workflows defined in the Identity System to create users and groups and delete users. The data available to be passed in a workflow request is limited by the SSPI interface of WebLogic, as follows:
Create User: The Userid, Password, and Description parameters are available to the SSPI while making a Create User request.
Delete User: The only attribute that is available while deleting a user is Userid.
Create Group: The parameters available while creating a group are Name and Description.
It is possible to define a workflow that uses values for these attributes. It is also possible to send constant values for more attributes as shown, in the following sample workflow definition in Table 10-3.
Table 10-3 Workflow Fields and Values
| Workflow Field | Sample Workflow Values |
|---|---|
|
Workflow Name |
Name generated by the Oracle Access Manager BEA SSPI Create User Workflow. |
|
Workflow Type |
Create User |
|
Workflow DN |
obworkflowid=wfqs20020806T0907402920,obcontainerId=workflo wDefinitions,OU=Oblix,OU=Company,DC=qalab-vduong,DC=oblix ,DC=com |
|
Workflow Status |
Enabled |
|
Description |
Workflow generated for COREidBEASSPI |
|
Target |
Company:OU=Company,DC=qalab-vduong,DC=oblix,DC=com |
|
Workflow Domain |
OU=Company,DC=qalab-vduong,DC=oblix,DC=com |
|
Workflow Steps |
Step 1: Name: Initiate Attribute Name: LoginID (Required) Attribute Name: Password (Required) Attribute Name: Name (Required) Participant: admin Step 2: Name: Enable Entry Condition: 1. true:false |
Following are the corresponding parameters from the NetPointProvidersConfig.properties file:
OBWebPass.CreatUserWorkFlowID=wfqs20020806T0907402920, obcontainerId=workflowDefinitions, OU=Oblix, OU=Company,DC=qalab-vduong,DC=oblix,DC=com OBWebPass.CreatUserWorkFlowDomain=OU=Company,DC=lab-vduong,DC=oblix,DC=com In this file, $UID$ and $PASSWD$ denote value of login attribute and password, respectively. The placeholders are passed to the workflow as is and are written to the user profile. At runtime, both $UID$ and $PASSWD$ are replaced with values obtained for the login attribute and password. OBWebPass.CreatUserWorkFlowNumOfFields=3 OBWebPass.CreatUserWorkFlowAttrName_1=cn OBWebPass.CreatUserWorkFlowAttrValue_1=Name of $UID$ OBWebPass.CreatUserWorkFlowAttrName_2=uid OBWebPass.CreatUserWorkFlowAttrValue_2=$UID$ OBWebPass.CreatUserWorkFlowAttrName_3=userPassword OBWebPass.CreatUserWorkFlowAttrValue_3=$PASSWD$ OBWebPass.CreatUserWorkFlowComment=Added user $UID$ from WebLogic portal server.
If the workflow is modified to use different attributes, the preceding sample lines in the NetPointProvidersConfig.properties file need to change. If workflow is modified to use another attribute, the DS attribute name must be specified in this file.
For example, if you change the first attribute from cn Name to cn Mail (that is obmail in DS) then do the following:
OBWebPass.CreatUserWorkFlowAttrName_1=obmail
OBWebPass.CreatUserWorkFlowAttrValue_1= $UID$@company.com
Similarly, if this is a new parameter being added to the workflow, you need to increase the number of fields and add two new lines for attribute:
Increase the number of fields as indicated in the following:
OBWebPass.CreatUserWorkFlowNumOfFields=4
Add two new lines, as indicated in the following:
OBWebPass.CreatUserWorkFlowAttrName_4=obmail
OBWebPass.CreatUserWorkFlowAttrValue_4=$UID$@company.com
The same approach is to be followed during group creation and user deletion. For group deletion, determination of the workflow to be used is made by Oracle Access Manager. The delete group operation requires only the Group DN, which is obtained from the Portal Admin interface at runtime.
The following configuration files are required for the integration of Oracle Access Manager and WebLogic:
The NetPointProvidersConfig.properties file describes all common configuration items. There are also items written by the installer when you select the Typical/Advanced install of the Security Provider for WebLogic. A sample file containing all of the parameters in the
A sample file containing all of the parameters in the SampleNetPointProvidersConfig.properties is located in:
Security_Provider_install_dir/examples
where Security_Provider_install_dir is the directory where the Security Provider for WebLogic is installed. Table 10-4 describes these parameters.
Table 10-4 NetPointProvidersConfig.properties
| Parameter | Description and Value |
|---|---|
|
ObDebugMode |
Specifies whether Oracle Access Manager debugging information is recorded in the WebLogic log files. Default=false |
|
ObRoles.Cache.TTL |
Specifies the length of time (in seconds) for which security roles are cached. Default=60 seconds |
|
ObRoles.Cache.CleanupSchedule |
Specifies the length of time (in seconds) after which expired items in the Roles cache are flushed. This is to reclaim memory. Default=60 seconds |
|
ObAuthorization.ActionOn UnprotectedResource |
Specifies default access to resources not protected by Oracle Access Manager. Default=allow |
|
Ob_InstallDir |
Specifies the installation directory for the Oracle Access Manager Security Provider. |
|
OB_AuthnSchemeResourceTypeName |
The Security Provider uses a special policy to authenticate users in WebLogic. The resource type specified on this parameter is used in this special authentication policy. This resource type contains a resource with a URL prefix of /Authen/Basic. Value: Name of the resource type. |
|
OB_AuthnSchemeResourceName |
The Security Provider uses a special policy to authenticate users in WebLogic. The resource specified on this parameter is used in this special authentication policy. This resource contains a URL prefix of /Authen/Basic. Value: Name of the resource. |
|
ObAuthentication.Anonymous. ResourceName |
The name of the resource used in the policy for anonymous authentication. |
|
OB_AuthnSchemeOperation |
The operations specified on the resource for this policy. Example: LOGIN |
|
ObAuthentication.LoginIdParam |
The userID challenge parameter that is used in the authentication scheme for the policy. This value is the same as the userID challenge parameter specified in the credential_mapping plug-in. Example: userid |
|
ObAuthentication.passwordParam |
The password challenge parameter that is used in the authentication scheme for the policy. This value is the same as the password challenge parameter specified in the validate_password plug-in. Example: password |
|
OB_AuthzActionType |
The authorization action that retrieves the user's login ID from the ObSSOCookie. Example: WL_REALM |
|
OB_AuthzActionName |
The action that retrieves the user's login ID from the ObSSOCookie. Example: uid |
|
ObFormAuthenticationSSO.Dummy UserName |
This dummy user name is used with a form login when single sign-on is configured. In this scenario, there is no WebGate on the proxy HTTP server. See "Completing Advanced Installation" for details. |
|
ObWebAppResourceTypes |
WebLogic resource types that are used for Web applications. |
|
ObRoles.ResourceType |
This parameter specifies the resource type defined for the policy that retrieves the user's role information. Example: wl_authen |
|
ObRoles.J2EEResourceType |
This parameter supports J2EE_Role type resource in Security Provider for WebLogic. Example: J2EE_Role1 |
|
ObRoles.ResourceName |
This parameter specifies the URL prefix of the resource (not the resource type) defined for the policy that retrieves the user's role information. Example: /Authen/Roles |
|
ObRoles.ResourceOperation |
The operation specified on the resource in this policy. Example: LOGIN |
|
ObRoles.J2EEResourceOperation |
This parameter supports J2EE_Role type resource operation for J2EE_Role type resource in Security Provider for WebLogic Example: IN |
|
ObRoles.ActionType |
The action specified on the authorization rule for the policy that obtains the user's role. Example: WL_REALM |
|
ObRoles.UseRoleBasedPolicies |
Set this to true if you want to create role based policies for Web and EJB applications. Set this to false for resource based policies. Important: Do not change the value once this parameter has been set. |
|
ObWebAndEjbResourceTypes |
This parameter provides a list of Web and EJB resource types. Value: <url>,<web>,<ejb> |
|
ObAuthorization.AbstainMapsTo |
If you do not want to use the Abstain result of an isAuthorized call, you can map the result to allow or deny. See "Completing Advanced Installation" for details. |
|
ObAuthorization.OnDenyRedirectTo Url |
If access to a resource is denied, then you can redirect the user to this page. This is optional. |
|
OB_LogLevel |
The logging level that is recorded in the log file. Values are none, info, and debug. This is optional. |
|
OB_LogFileName |
The file name for log messages. Default = install_dir/log. This is optional. |
|
OB_LogMilliSeconds |
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. This is optional. |
|
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 section. This is optional. |
|
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 the example provided in the previous paragraph, 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. This is Mandatory. |
|
OB_WebPassIsProtected |
Values are true and false. If WebPass is protected, set value=true. This is mandatory. |
|
OB_AdminUserName |
Oracle Access Manager requires the Admin username and password to make IdentityXML calls to the WebPass. This is mandatory. |
|
OB_AdminUserCreds |
Oracle Access Manager requires the Admin username and password to make IdentityXML calls to the WebPass. Without the password the Security Provider 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. This is mandatory. |
|
OB_CookieDomain |
The cookie domain specified in the WebGate installer configuration. Needed if WebPass is protected. For example, .xyz.com. This is mandatory. |
|
OB_CookiePath |
The cookie path specified in the WebGate configuration. Needed if WebPass is protected. Default = /. This is mandatory. |
|
OB_WebPassSSLEnabled |
Specifies whether WebPass needs HTTPS connection. Values are true and false. Default = false. This is Mandatory. |
|
OB_UserAttr |
The unique user identification (for example, uid). This is mandatory. |
|
OB_UserSearchAttr |
The DN prefix for users from LDAP (for example, cn). This is mandatory. |
|
OB_GroupSearchAttr |
The DN prefix for groups from LDAP (for example, cn). This is mandatory. |
|
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=com The ADDomain must be the same as the default defined in the Identity System. This is optional. |
|
OB_WebPassXPIRecordsReturned |
Optional. The number of records to return for getUsers or getGroups. Default = return all. This is 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. This is 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. This is 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). This is optional. |
|
OB_GroupMembersCache_timeout |
Specifies the timeout for cache of list of groups and the list of members in each group. This is optional. |
|
OB_UserAttributesCache_enabled |
Enables Caching of User Attributes. Values are true and false. This is optional. |
|
OB_UserAttributesCache_timeout |
The timeout for the cache of user attributes. Timeout is for the whole cache. This is optional. |
|
OB_UserAttributesCacheElement_timeout |
The timeout for the cached user attributes. The Timeout is per user. This is Optional. |
|
OB_GroupAttributesCache_enabled |
Enables Caching of Group Attributes. Values are true and false. This is optional. |
|
OB_GroupAttributesCache_timeout |
The timeout for the cache of group attributes. Timeout is for the whole cache. This is optional. |
|
OB_GroupAttributesCacheElement_timeout |
The timeout for the cached group attributes. The Timeout is per group. This is optional. |
|
OB_Keystore |
Specifies the keystore file used by the Security Provider for WebLogic SSPI 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: install_dir/oblix/config/jssecacerts. This is optional. |
|
OB_KeystorePassword |
The password for the keystore. This is optional. |
|
OB_UserTabId |
For future use. Do not change the default. Default = Employees |
|
OB_GroupTabId |
For future use. Do not change the default. Default = Groups |
|
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.
This is 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. This is optional. |
|
OB_UserPasswordAttr |
User Password Attribute. Example: userpassword. This is mandatory. |
|
OB_UserDescriptionAttr |
User Description Attribute. Example: description. This is mandatory. |
|
OBDisableEveryoneGroupCheck |
Parameter to enable or disable the everyone group check. Values are true and false.The default value is false. Setting this parameter to false enables everyone group check. Setting this parameter to true disables everyone group check. |
|
OBWebPass.CreatUserWorkFlowID |
WorkflowID for create user workflow. This is mandatory if user creation is supported. |
|
OBWebPass.CreatUserWorkFlow Domain |
WorkflowDomain for create user workflow. This is mandatory if user creation is supported. |
|
OBWebPass.CreatUserWorkFlow NumOfFields |
Number of attributes present in the create user workflow. This is mandatory if user creation is supported. |
|
OBWebPass.CreatUserWorkFlow AttrName_{number} OBWebPass.CreatUserWorkFlow AttrValue_{number} pair |
Name/Value pair for an attribute during user creation. |
|
OBWebPass.CreatUserWorkFlow Comment |
Comment while creating a user. |
|
OBWebPass.DeactivateUserWorkFlowID |
WorkflowID for delete user workflow. This is mandatory if user deletion is supported. |
|
OBWebPass.DelUserWorkFlowNum OfFields |
Number of attributes present in the delete user workflow. This is mandatory if user deletion is supported. |
|
OBWebPass.DelUserWorkFlowAttr Name_{number} OBWebPass.DelUserWorkFlowAttr Value_{number} pair |
Name/ Value pair for an attribute during user deletion. |
|
OBWebPass.DelUserWorkFlow Comment |
Comment while deleting a user. |
|
OB_GroupIDAttr |
Group Name Attribute. Example: cn. This is mandatory. |
|
OB_GroupDescriptionAttr |
Group Description Attribute. Example: description. This is mandatory. |
|
OB_GroupUniqueMemberAttr |
Group Uniquemenber Attribute. Example: uniquemenber. This is mandatory. |
|
OBWebPass.CreatGroupWorkFlowID |
WorkflowID for create group workflow. This is mandatory if group creation is supported. |
|
OBWebPass.CreatGroupWorkFlow Domain |
WorkflowDomain for create group workflow. This is mandatory if group creation is supported. |
|
OBWebPass.CreatGroupWorkFlow NumOfFields |
Number of attributes present in the create group workflow. This is mandatory if group creation is supported. |
|
OBWebPass.CreatGroupWorkFlow AttrName_{number} OBWebPass.CreatGroupWorkFlow AttrValue_{number} pair |
Name/ Value pair for an attribute during group creation. |
|
OBWebPass.CreatGroupWorkFlow Comment |
Comment while creating a group. |
Table 10-5 describes the NetPointWeblogicTools.properties file located in:
SecurityProvider_install_dir/oblix/tools/npWLTools
where SecurityProvider_install_dir is the directory where the Security Provider for WebLogic is installed.
This file contains information on the WebLogic policy domain.
Table 10-5 SampleNetPointWebLogicTools.properties Parameters
| Parameter | Description and Value |
|---|---|
|
ObWLTools.Debug |
Creates a debug file. Default = true |
|
ObWLTools.LogFile |
Creates a log file. Default = NetPointWeblogicTools.log |
|
ObPolicyDomain.Name |
The WebLogic domain name created by the Policy Deployer. Default = SecuProvForWeblogic |
|
ObPolicyDomain.Description |
Description of the WebLogic Domain. |
|
ObPolicyDomain.LoginAttribute |
The return attribute in the action of an authentication policy that retrieves the user's login ID from the ObSSOCookie. The return attribute is necessary for Oracle Access Manager single sign-on. Default = uid |
|
ObWLTools.SetupInitialNetpointSSPIPolicies |
Sets up the initial Oracle Access Manager policies for WebLogic such as /Authen/Bank. Use the default value when you first run the Oracle Access Manager Policy Deployer tool. When you run the tool subsequently, change value to false. Default = true |
|
ObWLTools.DeployPolicy |
If set to true, the tool reads the NetPointDeployPolicy.txt file and creates the policies in Oracle Access Manager. |
|
ObWLTools.UnDeployPolicy |
Deletes policies. Default = false |
|
ObWLSDomain.Dir |
The local directory where the WebLogic domain is located. Default = c:/bea/user_projects/mydomain |
|
ObWLAuthenticationScheme. Name |
The authentication scheme used for WebLogic. This should be created manually before running the tool. Default = Oracle WebLogic Access and Identity |
|
ObWLNoneAuthenticationScheme. Name |
The Anonymous authentication scheme used for WebLogic. This should be created manually before running the tool. Default = Oracle WebLogic Anonymous Authentication |
|
ObWLWebResource.usingIdentityAssertion |
Whether identity assertion is used to protect Web applications. Default=false. |
|
ObWLWebResource.proxyPrefix |
The string trimmed from the beginning of the URL that the user originally specifies, before the request is forwarded to the WebLogic Server. For example, if the URL http://myWeb.server.com/weblogic/foo is requested, the URL forwarded to the WebLogic Server is: http://myWeb.server.com:7001/foo The part of the request that is trimmed is what you specify on the ObWLWebResource.proxyPrefix parameter. |
The following are issues to consider when implementing the Security Provider for WebLogic SSPI on Active Directory.
The steps to configure Security Provider for WebLogic SSPI for an Active Directory Forest follow.
To configure the Security Provider for an Active Directory forest
In the Access System Console, create a new Access and Identity 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. See "Supported Versions and Platforms".
You need to complete step 2 only if you did not create an administrator during pre-installation setup. Otherwise, skip to step 3.
Create a WebLogic administrator in Oracle Access Manager with View and Delegated Administration rights and ensure that the administrator's login identification is unique.
Specify the WebLogic 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 NetPointProvidersConfig.properties file as described in"NetPointProvidersConfig.properties".
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 NetPointProvidersConfig.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 the Identity System.
See the Oracle Access Manager Identity and Common Administration Guide for more information.
To Prepare the BEA WebLogic Server 8.1.x
Ensure that your BEA WebLogic server 8.1.3 installation includes Java 1.4, which is required for this integration.
On an HP-UX 11i machine, ensure that the following Java-related patches are installed:
| Patch numbers | |||
|---|---|---|---|
| PHCO_26060 | PHCO_26111 | PHCO_27731 | PHCO_28425 |
| PHCO_29633 | PHCO_29959 | PHKL_18543 | PHKL_20228 |
| PHKL_23226 | PHKL_23409 | PHKL_24064 | PHKL_26008 |
| PHKL_27207 | PHKL_27282 | PHKL_28488 | PHKL_28766 |
| PHKL_29434 | PHKL_30073 | PHKL_30190 | PHNE_23003 |
| PHNE_29473 | PHSS_17535 | PHSS_24303 | PHSS_26972 |
| PHSS_26974 | PHSS_26976 | PHSS_28879 | PHSS_29369 |
| PHSS_29744 | PHSS_30010 | PHSS_30048 | PHSS_30260 |
| PHSS_30500 |
Detailed information about these patches is available at the following web site:
After installing the BEA SSPI package for HP-UX 11.11, you must set up NetPointRealm in the WebLogic domain by running a script, which, by default, does not have execute permission. Therefore, you must manually assign permission on HP-UX 11.11, then run the setupNetPointRealm.sh script.
The NetPointIdentityAsserter provider authenticates the user through the ObSSOCookie. To facilitate this, you must set up a proxy server such as Apache with a WebGate installed on it along with a WebLogic module loader.
When the WebGate successfully authenticates the user, it generates an ObSSOCookie. Using the WebLogic module loader, Apache redirects the request to the WebLogic server with the ObSSOCookie set, at which point the NetPointIdentityAsserter is invoked.
However, the WebLogic module loader for Apache 1.3.x is not shipped with BEA WebLogic Server 8.1.3. To test this functionality, you need a proxy server on a platform, such as Solaris. This functionality of the Oracle Access Manager SSPI has been tested against a proxy server on Solaris. It involves the following steps:
Set up a proxy server (Apache, for example) on a platform other than WebLogic (Solaris, for example).
Install a WebGate along with a WebLogic module loader on this proxy server.
Test user authentication and redirection to the WebLogic server.
You can manage Oracle Access Manager users and groups through the WebLogic Server Console.
If you are migrating or patching the Security Provider for WebLogic SSPI from Oracle Access Manager v7.0.2 (or an earlier version) to Oracle Access Manager 10g (10.1.4.0.1), take care to ensure that all the parameters in NetPointProvidersConfig.properties file are set up as specified in"NetPointProvidersConfig.properties". Also, read the section "Preparing the WebLogic Environment".
The procedures for setting cookies and header attributes for SSPI are similar to those for a WebGate.
The cookie and header name and values are specified as return actions for policies defined in NetPoint. SSPI recognizes WL_COOKIE and WL_HeaderVar as return types for cookies and header attributes respectively.
Note that attributes and not actual headers are set in the http request. The attributes set in the request can be extracted by the target application using the httpservletrequest getAttribute () method. To ensure that these attributes can be extracted, make sure that the target application has access to the J2EE interface httpservletrequest.
The following list is organized alphabetically according to the title in bold and are useful to understand. See also "WebLogic Portal Admin Console Changes".
changeUserPassword Method: The old password will not be checked as all IDXML calls are made with admin credentials. In any case, the changePassword method is not called by the Portal Admin Console. The Portal Admin Console uses resetPassword method, which has been implemented.
Character Restrictions for User Names: The WebLogic Server Console imposes certain restrictions on characters allowed in user names. While all users are displayed correctly in the Console, user creation/user to role mapping must bind with these restrictions.
Escape Mechanism for BEA WebLogic Server Role Mapping Provider: The BEA WebLogic Server Role Mapping provider is used for defining roles in weblogic. Using the Role Mapping provider, users/groups can be assigned to roles. See "Additional Resources" for more details about WebLogic Security Roles.
This role mapper cannot handle various special characters in user and group names, even though LDAP permits these characters. To overcome this limitation, the Security Provider implements an escape mechanism that enables you to map any Oracle Access Manager group to WebLogic roles. Use Table 10-6 as a reference to read Oracle Access Manager groups in WebLogic Server/Portal Console.
Table 10-6 Read Oracle Access Manager Groups in WebLogic Server/Portal Console
| Special Character | Escaped to Sequence |
|---|---|
|
: |
:A |
|
(space) |
:B |
|
, (comma) |
:C |
|
- |
:D |
|
= |
:E |
|
? |
:F |
|
> |
:G |
|
# |
:H |
|
' (single inverted comma) |
:I |
|
" (double inverted comma) |
:J |
|
* |
:K |
|
< |
:L |
|
& |
:M |
|
~ |
:N |
|
( |
:O |
|
) |
:P |
|
{ |
:Q |
|
} |
:R |
|
\t |
:S |
|
% |
:T |
|
; |
:U |
|
| |
:V |
|
$ |
:W |
Group Description: Group description will not be available for display immediately after creating a group.
Group Members: Only immediate members of the group can be removed from the group. Only User members will be listed as members of group. This holds for nested groups too.
Group With Latin Characters: In the WebLogic Server Console, when trying to assign a group with "Latin Characters" as a parent group of another user/group, the operation fails because this interface in the console does not handle "Latin Characters".
Group Within a Group: In the WebLogic Portal Console, if you try to create a group inside another group, and the new group is created, it is not added to the parent group. You can add the created group to the desired group using the "Add group to Group" interface in the Console.
User/Group Workflows: In create user/group workflows only one value for each attribute (parameter) should be specified in the configuration file.
User/Group Display: Unique userid (uid) will be used for all display operations for users. Group DN will be used for all display operations for groups.
Wild Card Searches: These searches are supported for users and groups; the match is not case sensitive:
*: returns all user/groups
Foo*: returns all users/groups whose name starts with Foo
*Foo: returns all users/groups whose name ends with Foo
*Foo*: returns all users/groups whose name contains Foo
FooBar: only returns a user/group named "FooBar"
Note:
For users, a unique user identifier is matched against the pattern. However, for groups a common name is matched. For exact group searches, specify the entire group DN without escape characters.See also "WebLogic Portal Admin Console Changes".
The following WebLogic Portal Admin Console changes have occurred.
Building a Group Hierarchy Tree for the Oracle Access Manager Authentication Provider: When trying to search for groups in the WebLogic Portal Admin Console, a message may be displayed saying:
The Authentication Provider, Oracle Access Manager Authenticator, has not been configured for GUI tree mode
In this case, only one group can be searched at a time. You can use the following procedure to list all the groups in the Admin Console.
To enable the listing of all groups in the Admin Console
From the WebLogic Administration Portal main menu, select Service Administration.
In the left pane, select Authentication Hierarchy Service.
In the right pane, Provider to Add to Build List field, enter the name of Oracle Access Manager authentication provider exactly (including case sensitivity):
For example:
NetPointAuthenticator
Note:
You can find the name of Oracle Access Manager Authentication provider by selecting the Security Provider's tool and expanding the Authentication Providers node.Click Update & Build Tree.
Now, group hierarchies will be displayed for all operations where groups are involved.
Delegated Administration: In order for delegated administration roles to take effect, the PortalSystemDelegator role needs to be associated with the Oracle Access Manager group that was associated with the Admin role in the WebLogic Server Console during product setup.
Using the SSPI, you can configure only one Oracle Access Manager policy domain per WebLogic server instance. However, you can configure and apply a different policy domain to each WebLogic server. A role must have a uniform definition in all policy domains, although the role can be used in different ways in different policy domains.
SSPI maintains the following two configuration files in the WebLogic server domain directory:
NetPointProvidersConfig.properties NetPointResourceMap.conf
The parameters in these two files facilitate setup of different policy domains on different WebLogic servers. Thus, all the weblogic servers in an organization need not use the same policy domain.
The SSPI integration with WebLogic Server performs three main tasks: Authentication, Role Mapping, and Authorization.
For authentication, SSPI uses the OB_AuthnSchemeResourceName parameter in NetPointProvidersConfig.properties. You define a policy in Oracle Access Manager to protect the resource specified by this parameter. Specifying different names for this authentication parameter facilitates different authentication policies for different policy domains. By default, this parameter is /Authen/Basic.
The same principle applies to the policy defined for anonymous authentication through ObAuthentication.Anonymous.ResourceName. The default value for this parameter is /Authen/Anonymous.
Also, different role mapping policies can be defined in different policy domains through the role mapping parameter ObRoles.ResourceName, which resides in NetPointProvidersConfig.properties. By default, this parameter is /Authen/Roles.
For authorization, NetPointResourceMap.conf contains information about mapping WebLogic resources to Oracle Access Manager resources. For example, a WebLogic resource of type url maps to a Oracle Access Manager resource of type wl_url. To make different WebLogic servers refer to resource protection policies defined in different domains, specify different resource mappings for your various WebLogic servers.
For example, one WebLogic server can map url to wl_wrl for HTTP resources and protect resources of type wl_url in its policy domain. A second weblogic server can map url to weblogic_wrl for HTTP resources and protect resources of type weblogic_url in its policy domain.
Note:
For a given WebLogic server, the authentication and role mapping policies are picked up from a single policy domain, whereas for authorization, the policies used to protect resources are picked up from any domain that has a policy defined for the resource type being accessed.Problem: I get the following error when starting the WebLogic Server:
<May 23, 2003 1:44:07 AM PDT> <Error> <OblixSecurityProviders> <700021> <Authentication failed for user [admin]. Reason - Unprotected resource LOGIN Authen:/Authen/Basic used in an ObAuthenticationScheme or ObUserSession constructor.>
Solution: The authentication policy may be disabled or absent. See "Setting Up WebLogic Policies in Oracle Access Manager" for setup information.
Problem: I created a policy to protect web application (for example, /security) with an authorization rule to allow access to some users. But, in reality everyone is allowed access.
Solution: Ensure the following:
Enable the policy.
Do not use host identifiers.
Use the Access Tester to ensure that the policy is being evaluated for this resource and the user who is allowed to access the resource.
Note that the default behavior of Access Server is to allow access if the resource is not protected. This default behavior can be changed by modifying the "denyOnProtect" flag in the Access Server configuration.
Problem: I want to use the methods of the principal ObWLSUser object in an EJB.
Solution: You can use all the methods exposed by the Principal object, but not methods like "isAuthorized" that are present only in ObWLSUser object. This is because they make JNI calls to Access Manager SDK, which is not present on the client side except when the EJB is being run from another WebLogic Server using Oracle Providers. If you really want to execute methods like "isAuthorized" on the client side, then you must install the Access Manager SDK and call ObConfig.Init() before making any calls. A suggested solution is to get the session token from the ObWLSUser object and then use Access Manager SDK methods to execute methods such as isAuthorized.
Problem: The server does not start up. The log has the following entry
####<May 29, 2003 2:07:48 PM PDT> <OFF> <Unknown> <vjain> <examplesServer> <main> <<WLS Kernel>> <> <000000> <Message text not found - Can't locate bundle for class>
Solution: Security Provider's message resources are bundled in wlNetpoint.jar. Make sure that wlNetpoint.jar is present in the classpath. Refer to "Preparing the Environment" for details on setting up the required environment variables.
Problem: I get the following error:
<May 29, 2003 2:36:40 PM PDT> <Error> <OblixSecurityProviders> <700053> <Exception encountered when isProtected() called for the resource - Type=wl_svr, isEnabled=true, URL=/examplesServer, operation=default. Reason - The requested resource could not be mapped to a policy domain in the Policy database. Check if the corresponding directory service is up.>
Solution: The wl_svr resource type is probably enabled in NetpointResourceMap.txt but the resource type is not yet created in the Access System.
Problem: The installer does not write the complete file and the code expects some default values.
Solution: This problem occurs when some of the values are not specified in the properties file. Use the file in install_dir\weblogic8\examples and modify it for your environment.
For example, if an action is not specified for authen to get name later:
,Roles:{Regular=Regular} ,Resource:type=<url>, application=security, contextPath=/security, uri=/admin/edit.jsp, httpMethod=GET ,ContextHandler:HttpServletRequest ,ContextHandler:HttpServletResponse>
<Jun 10, 2003 3:37:21 PM PDT> <Debug> <OblixSecurityProviders> <000000> <OblixResource got from cache>
<Jun 10, 2003 3:37:21 PM PDT> <Debug> <OblixSecurityProviders> <000000> <Entering OblixDatabase.isProtected for resource Type=wl_url, isEnabled=true, URL=/security/admin/edit.jsp, operation=GET>
<Jun 10, 2003 3:37:21 PM PDT> <Debug> <OblixSecurityProviders> <000000> <Is resource protected? true>
<Jun 10, 2003 3:37:21 PM PDT> <Debug> <OblixSecurityProviders> <000000> <Entering OblixDatabase.isAccessAllowed for cn=Drusy Sails,ou=LHuman Resource,ou=Los Angles,ou=Dealer1k1,ou=Latin America,ou=Ford,o=Company,c=US on resource Type=wl_url, isEnabled=true, URL=/security/admin/edit.jsp, operation=GET>
<Jun 10, 2003 3:37:21 PM PDT> <Debug> <OblixSecurityProviders> <000000> <OblixDatabase.isAccessAllowed returned PERMIT>
<Jun 10, 2003 3:37:21 PM PDT> <Debug> <OblixSecurityProviders> <000000> <Found an authenticated principal of type ObWLSUser>
<Jun 10, 2003 3:37:21 PM PDT> <Debug> <OblixSecurityProviders> <000000> <Got a SSO token>
. . .
Solution: Set values for the following parameters as shown in the NetPointProvidersConfig.properties file:
ObAuthenticationScheme.AuthorizationRule.ActionType=WL_REALM
ObAuthenticationScheme.AuthorizationRule.ActionName=uid
Problem: I get the following stack.
<Jun 9, 2003 7:43:04 PM PDT> <Debug> <OblixSecurityProviders> <000000> <userName= [weblogic_system]> <Jun 9, 2003 7:43:04 PM PDT> <Debug> <OblixSecurityProviders> <000000> <Entering OblixDatabase.login() for user weblogic_system> <Jun 9, 2003 7:43:04 PM PDT> <Debug> <OblixSecurityProviders> <000000> <Authentication failed for [weblogic_system] with message Unprotected resource LOGIN Authen:/Authen/Basic8 used in an ObAuthenticationScheme or ObUserSession constructor. com.oblix.access.ObAccessException: Unprotected resource LOGIN Authen:/Authen/Basic8 used in an ObAuthenticationScheme or ObUserSession constructor. at com.oblix.access.ObUserSession.initCppSideAuthenticate(Native Method) at com.oblix.access.ObUserSession.<init>(ObUserSession.java:222) at com.oblix.weblogic.internal.OblixDatabase.login (OblixDatabase.java:185) . . .
Solution: Check the resource, operation and policy and authorization rules. Some resource is not protected.
Problem: I get the following stack.
at com.oblix.weblogic.security.providers.authentication. OblixLoginModuleImpl.login(OblixLoginModuleImpl.java:161) at weblogic.security.service.DelegateLoginModuleImpl.login (DelegateLoginModuleImpl.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at javax.security.auth.login.LoginContext.invoke (LoginContext.java:675) at javax.security.auth.login.LoginContext.access$000 (LoginContext.java:129) at javax.security.auth.login.LoginContext$4.run (LoginContext.java:610) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeModule (LoginContext.java:607) at javax.security.auth.login.LoginContext.login (LoginContext.java:534) at weblogic.security.service.PrincipalAuthenticator.authInternal (PrincipalAuthenticator.java:329) at weblogic.security.service.PrincipalAuthenticator.authenticate (PrincipalAuthenticator.java:282) at weblogic.security.service.SecurityServiceManager. doBootAuthorization (SecurityServiceManager.java:913) at weblogic.security.service.SecurityServiceManager.initialize (SecurityServiceManager.java:1036) at weblogic.t3.srvr.T3Srvr.initializeHere(T3Srvr.java:783) at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:627) at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:337) at weblogic.Server.main(Server.java:32) > <Jun 9, 2003 7:43:04 PM PDT> <Error> <OblixSecurityProviders> <700021> <Authentication failed for user [weblogic_system]. Reason - Unprotected resource LOGIN Authen:/Authen/Basic8 used in an ObAuthenticationScheme or ObUserSession constructor.> <Jun 9, 2003 7:43:04 PM PDT> <Debug> <OblixSecurityProviders> <000000> <ObUserSession ctor from username, password failed com.oblix.access.ObAccessException: Unprotected resource LOGIN Authen:/Authen/Basic8 used in an ObAuthenticationScheme or ObUserSession constructor. at com.oblix.access.ObUserSession.initCppSideAuthenticate(Native Method) at com.oblix.access.ObUserSession.<init>(ObUserSession.java:222) at com.oblix.weblogic.internal.OblixDatabase.login (OblixDatabase.java:185) at com.oblix.weblogic.security.providers.authentication. OblixLoginModuleImpl. login(OblixLoginModuleImpl.java:161) at weblogic.security.service.DelegateLoginModuleImpl.login (DelegateLoginModuleImpl.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at javax.security.auth.login.LoginContext.invoke (LoginContext.java:675) at javax.security.auth.login.LoginContext.access$000 (LoginContext.java:129) at javax.security.auth.login.LoginContext$4.run (LoginContext.java:610) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeModule (LoginContext.java:607) at javax.security.auth.login.LoginContext.login (LoginContext.java:534) at weblogic.security.service.PrincipalAuthenticator.authInternal (PrincipalAuthenticator.java:329) at weblogic.security.service.PrincipalAuthenticator.authenticate (PrincipalAuthenticator.java:282) at weblogic.security.service.SecurityServiceManager. doBootAuthorization (SecurityServiceManager.java:913) at weblogic.security.service.SecurityServiceManager.initialize (SecurityServiceManager.java:1036) at weblogic.t3.srvr.T3Srvr.initializeHere(T3Srvr.java:783) at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:627) at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:337) at weblogic.Server.main(Server.java:32) > <Jun 9, 2003 7:43:04 PM PDT> <Debug> <OblixSecurityProviders> <000000> <Entering OblixLoginModuleImpl.abort> <Jun 9, 2003 7:43:04 PM PDT> <Critical> <Security> <BEA-090402> <Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.> ****************************************************************** The WebLogic Server did not start up properly. Reason: weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted. ****************************************************************** . . .
Solution: You are probably missing the Oracle Access Manager configuration file in the WLS Domain directory.
Problem: I get the following stack.
<Jun 9, 2003 6:11:39 PM PDT> <Info> <WebLogicServer> <BEA-000377> <Starting WebLogic Server with Java HotSpot(TM) Client VM Version 1.4.1_02-ea-b01 from Sun Microsystems Inc.>
<Jun 9, 2003 6:11:41 PM PDT> <Info> <Configuration Management> <BEA-150016> <This server is being started as the administration server.>
<Jun 9, 2003 6:11:41 PM PDT> <Info> <Management> <BEA-141107> <Version: WebLogic Server 8.1 Thu Mar 20 23:06:05 PST 2003 246620
WebLogic XMLX Module 8.1 Thu Mar 20 23:06:05 PST 2003 246620 >
<Jun 9, 2003 6:11:43 PM PDT> <Notice> <Management> <BEA-140005> <Loading domain configuration from configuration repository at / export/home/bea81/user_projects/mydomain/./config.xml.>
<Jun 9, 2003 6:11:57 PM PDT> <Info> <Logging> <000000> <FileLogger Opened at ./myserver/myserver.log>
<Jun 9, 2003 6:12:03 PM PDT> <Error> <Unknown> <000000> <Unable to access undefined message, id=700025>
******************************************************************
The WebLogic Server did not start up properly.
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:306)
at java.lang.Class.newInstance(Class.java:259)
at weblogic.security.service.SecurityServiceManager. createSecurityProvider (SecurityServiceManager.java:1686)
at weblogic.security.service.RoleManager.initialize (RoleManager.java:147)
at weblogic.security.service.RoleManager.<init> (RoleManager.java:93)
at weblogic.security.service.SecurityServiceManager.doRole (SecurityServiceManager.java:1417)
at weblogic.security.service.SecurityServiceManager. initializeRealm (SecurityServiceManager.java:1271)
at weblogic.security.service.SecurityServiceManager.loadRealm (SecurityServiceManager.java:1216)
at weblogic.security.service.SecurityServiceManager. initializeRealms (SecurityServiceManager.java:1338)
at weblogic.security.service.SecurityServiceManager.initialize (SecurityServiceManager.java:1018)
at weblogic.t3.srvr.T3Srvr.initializeHere(T3Srvr.java:783)
at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:627)
at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:337)
at weblogic.Server.main(Server.java:32)
Caused by: com.oblix.weblogic.configuration.ConfigurationException: Unable to access undefined message, id=700025
at com.oblix.weblogic.configuration.OblixConfiguration. loadProperties (OblixConfiguration.java:106)
at com.oblix.weblogic.configuration.OblixConfiguration.<init> (OblixConfiguration.java:61)
at com.oblix.weblogic.configuration.OblixConfiguration.getInstance (OblixConfiguration.java:55)
at com.oblix.weblogic.internal.OblixDatabase.<init> (OblixDatabase.java:47)
at com.oblix.weblogic.internal.OblixDatabase.getInstance (OblixDatabase.java:39)
at com.oblix.weblogic.security.providers.roles. OblixRoleMapperProviderImpl.<clinit>(OblixRoleMapperProviderImpl.j ava:51)
... 18 more
******************************************************************
Solution: The Oblix Jar file is not correctly packaged.
The following URLs are provided for background:
Terminology for the Newly Introduced Concepts: http://e-docs.bea.com/wls/docs81/secintro/terms.html
Security Introduction:
Security framework whitepaper:
http://www.bea.com/content/news_events/white_papers/BEA_WL_Server_TechSecurity_wp.pdf
Types of WebLogic Resources:
Roles:
Web application security deployment descriptors:
http://e-docs.bea.com/wls/docs81/security/thin_client.html#1045984
EJB security deployment descriptors:
http://e-docs.bea.com/wls/docs81/security/ejb_client.html#1033936
WebLogic Security Roles: http://e-docs.bea.com/wls/docs81/secwlres/secroles.html
