Note: The Realm Adapter Auditing, Adjudication, and Authorization providers are only available when using Compatibility Security. For information about those providers, see Using Compatibility Security.
When Do I Need to Configure a Security Provider?
By default, most of the configuration work for security providers is done. However, the following circumstances require you to configure attributes on a security provider:
To protect private keys and trusted certificate authorities in a keystore rather than a flat file, configure the WebLogic Keystore provider. For more information, see Configuring a WebLogic Keystore Provider.
Note: Custom keystore providers are not supported in this release of WebLogic Server.
To use an LDAP server other than the embedded LDAP server, configure one of the LDAP Authentication providers. The LDAP authentication provider can be used instead of or in addition to the WebLogic Authentication provider. For more information, see Configuring an LDAP Authentication Provider.
To use existing users and groups stored in an 6.x security realm (for example, the 6.x Windows NT, UNIX, RDBMS security realms or 6.x custom security realms), configure the Realm Adapter Authentication provider. The Realm Adapter Authentication provider can be used instead of or in addition to the WebLogic Authentication provider. For more information, see Configuring a Realm Adapter Authentication Provider.
Note: There are no equivalents to the 6.x Windows NT, UNIX, RDBMS security realms in this release of WebLogic Server. Therefore, BEA recommends using the Realm Adapter Authentication provider to access the users and groups stored in these security realms.
When creating a new security realm, configure security providers for that new realm. When using the default realm (myrealm), the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Credential Mapping, and Role Mapping providers are already configured. For more information, see Creating a New Security Realm.
When adding a custom security provider to a security realm or replacing one of the WebLogic security providers with a custom security provider, configure attributes for the custom security provider. When writing a custom security provider, you can implement attributes that are configurable through the WebLogic Server Administration Console. However, those attributes are implementation-specific and are not addressed in this manual. For more information, see "Writing Console Extensions for Custom Security Providers" in Developing Security Providers for WebLogic Server.
The remainder of this section describes the attributes that can be set for each security provider.
Configuring a WebLogic Adjudication Provider
When multiple Authorization providers are configured in a security realm, each may return a different answer to the "is access allowed" question for a given resource. This answer may be PERMIT, DENY, or ABSTAIN. Determining what to do if multiple Authorization providers do not agree on the answer is the primary function of the Adjudication provider. Adjudication providers resolve authorization conflicts by weighting each Authorization provider's answer and returning a final decision.
Each security realm must have an Adjudication provider configured. You can use either a WebLogic Adjudication provider or a custom Adjudication provider in a security realm. This section describes how to configure a WebLogic Adjudication provider. For information about configuring a custom security provider (including a custom Adjudication provider), see Configuring a Custom Security Provider
To configure a WebLogic Adjudication provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm.)
Expand the Providers node.
Click Adjudicators.
The Adjudicators table displays the name of the default Adjudication provider for the realm that is being configured.
Click the Configure a new Default Adjudicator... link.
When working in an existing security realm, click the Replace with a new Default Adjudicator... link.
Optionally, on the General tab, set the Require Unanimous Permit attribute.
The Require Unanimous Permit attribute determines how the WebLogic Adjudication provider handles a combination of PERMIT and ABSTAIN votes from the configured Authorization providers.
If the attribute is enabled, all Authorization providers must vote PERMIT in order for the Adjudication provider to vote true. By default, the Require Unanimous Permit attribute is enabled.
If the attribute is disabled, ABSTAIN votes are counted as PERMIT votes. To disable the Require Unanimous Permit attribute, click the checkbox.
Click Apply to save your changes.
Reboot WebLogic Server.
Configuring a WebLogic Auditing Provider
Auditing is the process whereby information about operating requests and the outcome of those requests are collected, stored, and distributed for the purposes of non-repudiation. In other words, Auditing providers produce an electronic trail of computer activity. Configuring an Auditing provider is optional. The default security realm (myrealm) does not have an Auditing provider configured.
You can use either a WebLogic Auditing provider or a custom Auditing provider in a security realm. This topic describes how to configure a WebLogic Auditing provider. For information about configuring a custom security provider (including a custom Auditing provider), see Configuring a Custom Security Provider
Warning: Using an Auditing provider affects the performance of WebLogic Server even if only a few events are logged.
To configure the WebLogic Auditing provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers node.
Click Auditors.
The Auditors table displays the name of the default Auditor for the realm that is being configured.
Click the Configure a new Default Auditor... link.
The General tab appears.
Choose the severity level appropriate for your WebLogic Server deployment.
The Auditing provider audits a particular security event based on the event level specified in the Severity attribute. Auditing can be initiated when the following levels of security events occur:
INFORMATION
WARNING
ERROR
SUCCESS
FAILURE
Click Create to save your changes.
Reboot WebLogic Server.
All auditing information recorded by the WebLogic Auditing provider is saved in WL_HOME\yourdomain\yourserver\DefaultAuditRecorder.log. Although, an Auditing provider is configured per security realm, each server writes auditing data to its own log file in the server directory. The WebLogic Auditing provider logs the following events:
Table 3-1 WebLogic Auditing Provider Events
Audit Event
Indicates...
AUTHENTICATE
Simple authentication (username and password) occurred.
ASSERTIDENTITY
Perimeter authentication (based on tokens) occurred.
USERLOCKED
A user account is locked because of invalid login attempts.
USERUNLOCKED
The lock on a user account is cleared.
USERLOCKOUTEXPIRED
The lock on a user account expired.
ISAUTHORIZED
An authorization attempt occurred.
ROLEEVENT
A getRoles event occurred.
ROLEDEPLOY
A deployRole event occurred.
ROLEUNDEPLOY
An undeployRole event occurred.
POLICYDEPLOY
A deployPolicy event occurred.
POLICYUNDEPLOY
An undeployPolicy event occurred.
Choosing an Authentication Provider
Authentication is the process whereby the identity of users or system processes are proved or verified. Authentication also involves remembering, transporting, and making identity information available to various components of a system when that information is needed.
The WebLogic Server security architecture supports: certificate-based authentication directly with WebLogic Server; HTTP certificate-based authentication proxied through an external Web server; perimeter-based authentication (Web server, firewall, VPN); and authentication based on multiple security token types and protocols.
Authentication is performed by an Authentication provider. WebLogic Server offers the following types of Authentication providers:
The WebLogic Authentication provider accesses user and group information in the embedded LDAP server.
LDAP Authentication providers access external LDAP stores. WebLogic Server provides LDAP Authentication providers which access Open LDAP, Netscape iPlanet, Microsoft Active Directory and Novell NDS stores. An LDAP Authentication provider can also be used to access other LDAP stores. However, you must choose an pre-defined LDAP providers and customize it.
The Realm Adapter Authentication provider accesses user and group information stored in 6.x security realms.
The WebLogic Identity Assertion provider validates X.509 and IIOP-CSIv2 tokens and can use a user name mapper to map that token to a user in a WebLogic Server security realm.
In addition, you can use:
Custom Authentication providers, which offer different types of authentication technologies.
Custom Identity Assertion providers, which support different types of tokens.
Note: The WebLogic Server Administration Console refers to the WebLogic Authentication provider as the Default Authenticator and the WebLogic Identity Assertion provider as the Default Identity Asserter.
Each security realm must have one at least one Authentication provider configured. The WebLogic Security Framework is designed to support multiple Authentication providers (and thus multiple LoginModules) for multipart authentication. Therefore, you can use multiple Authentication providers as well as multiple types of Authentication providers in a security realm. For example, if you want to use both a retina-scan and a username/password-based form of authentication to access a system, you configure two Authentication providers.
The way you configure multiple Authentication providers can affect the overall outcome of the authentication process. Authentication providers are called in the order in which they are configured. Therefore, use caution when configuring Authentication providers. Use the JAAS Control Flag attribute to set up login dependencies between Authentication providers and allow single-sign on between providers. For more information, see Setting the JAAS Control Flag Attribute.
Configuring an Authentication Provider: Main Steps
To configure an Authentication provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers-->Authentication Providers nodes.
The Authenticators table displays the name of the default Authentication and Identity Assertion providers.
Choose an Authentication and/or Identity Assertion provider.
Configure a new iPlanet Authenticator...
Configure a new Realm Adapter Authenticator...
Configure a new Active Directory Authenticator...
Configure a new Default Authenticator...
Configure a new Default Identity Asserter...
Configure a new OpenLDAP Authenticator...
Configure a new Novell Authenticator...
Go to the appropriate sections to configure an Authentication and/or Identity Assertion provider.
After you finish configuring Authentication and/or Identity Assertion providers, reboot WebLogic Server.
Setting the JAAS Control Flag Attribute
When you configure multiple Authentication providers, use the JAAS Control Flag attribute on the Authenticator-->General tab to control how the Authentication provider are used in the login sequence.
The definitions for the JAAS Control Flag values are as follows:
REQUIRED—The Authentication provider is always called, and the user must always pass its authentication test.
SUFFICIENT—If the user passes the authentication test of the Authentication provider, no other Authentication providers are executed (except for Authentication providers with the JAAS Control Flag set to REQUIRED) because the user was sufficiently authenticated.
REQUISITE—If the user passes the authentication test of this Authentication provider, other providers are executed but can fail (except for Authentication providers with the JAAS Control Flag set to REQUIRED).
OPTIONAL—The user is allowed to pass the Authentication test of these Authentication provider. However, if all Authentication providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the providers.
When additional Authentication providers are added to an existing security realm, by default the Control Flag attribute is set to OPTIONAL. If necessary, changing the setting of the Control Flag so that the Authentication provider works properly in the authentication sequence.
Note: The WebLogic Server Administration Console actually sets the JAAS Control Flag to OPTIONAL when creating a security provider. MBeans for the security providers actually default to REQUIRED.
Configuring an LDAP Authentication Provider
WebLogic Server does not support or certify any particular LDAP servers. Any LDAP v2 or v3 compliant LDAP server should work with WebLogic Server. The following LDAP directory servers have been tested:
Requirements for Using an LDAP Authentication Provider
If an LDAP Authentication provider is the only configured Authentication provider for a security realm, you must have the Admin role to boot WebLogic Server and use a user or group in the LDAP directory. Do one of the following in the LDAP directory:
By default in WebLogic Server, the Admin role includes the Administrators group. Create an Administrators group in the LDAP directory. Make sure the LDAP user from which you want to boot WebLogic Server is included in the group.
The Active Directory LDAP directory has a default group called Administrators. Add the user from which you will be booting WebLogic Server to the Administrators group and define the Group Base Distinguished Name (DN) attribute so that the Administrators group is found.
If you do not want to create an Administrators group in the LDAP directory (for example, because the LDAP directory uses the Administrators group for a different purpose), create a new group (or use an existing group) in the LDAP directory and include the user from which you want to boot WebLogic Server in that group. In the WebLogic Server Administration Console, assign that group the Admin role.
Configuring a LDAP Authentication Provider
To configure an LDAP Authentication provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers-->Authentication Providers nodes.
The Authenticators table displays the name of the default Authentication and Identity Assertion providers.
Choose an LDAP Authentication provider.
Configure a new iPlanet Authenticator...
Configure a new Active Directory Authenticator...
Configure a new OpenLDAP Authenticator...
Configure a new Novell Authenticator...
If you using multiple Authentication providers, define a value for the Control Flag attribute on the General tab. The Control Flag attribute determines how the LDAP Authentication provider is used with other LDAP Authentication providers. For more information, see Configuring an LDAP Authentication Provider.
Click the LDAP tab under the Configuration tab for the LDAP Authentication provider you want to use.
For example, click the iPlanet LDAP tab under the iPlanet Configuration tab.
Enable communication between WebLogic Server and the LDAP server by defining values for the attributes shown on the LDAP tab.
The following table describes the attributes you set on the LDAP tab.
Table 3-2 Attributes on the LDAP Tab
Attribute
Description
Host
The host name of the computer on which the LDAP server is running.
Port
The port number on which the LDAP server is listening. If you want WebLogic Server to connect to the LDAP server using the SSL protocol, use the LDAP server's SSL port in this attribute.
SSL Enabled
Option for enabling the SSL protocol to protect communications between the LDAP server and WebLogic Server. Disable this attribute if the LDAP server is not configured to use the SSL protocol.
Principal
The Distinguished name (DN) of the LDAP user used by WebLogic Server to connect to the LDAP server. Generally, this user is the system administrator of the LDAP directory server. If you want to change passwords, this attribute must be the system administrator.
Credential
Password that authenticates the LDAP user defined in the Principal attribute.
Cache Enabled
Enables the use of a data cache with the LDAP server.
Cache Size
Maximum size of lookups in cache. The default is 32kb.
Cache TTL
Number of seconds to retain the results of an LDAP lookup.
To save your changes, click Apply.
Click the Details tab to configure additional attributes that control the behavior of the LDAP server.
The following table describes the attributes you set on the Details tab.
Table 3-3 Attributes on the Details Tab
Attribute
Description
Group Membership Searching
Controls whether group searches are limited in depth or unlimited. This attribute controls how deeply a search should recursive into nested groups. For configurations that use only the first level of nested group hierarchy, this attribute allows improved performance during user searches by limiting the search to the first level of the group.
If a limited search is specified, the Max Group Membership Search Level attribute must be specified.
If an unlimited search is specified, the Max Group Membership Search Level attribute is ignored.
Max Group Membership Search Level
Controls the depth of a group membership search if the Group Membership Searching attribute is specified. Possible values are:
0—Indicates only direct groups will be found. That is, when searching for membership in Group A, only direct members of Group A will be found. If Group B is a member of Group A, the members will not be found by this search.
Any positive number—Indicates the number of levels to search. For example, if this attribute is set to 1, a search for membership in Group A will return direct members of Group A. If Group B is a member of Group A, the members of Group B will also be found by this search. However, if Group C is a member of Group B, the members of Group C will not be found by this search.
Follow Referrals
Specifies that a search for a user or group within the LDAP Authentication provider will follow referrals to other LDAP servers or branches within the LDAP directory. By default, this attribute is enabled.
Bind Anonymously On Referrals
By default, an LDAP Authentication provider uses the same DN and password used to connect to the LDAP server when following referrals during a search. If you want to connect as an anonymous user, enable this attribute. Contact your LDAP system administrator for more information.
Results Time Limit
The maximum number of milliseconds for the LDAP server to wait for results before timing out. If this attribute is set to 0, there is no maximum time limit. The default is 0.
Connect Timeout
The maximum time in seconds to wait for the connection to the LDAP server to be established. If this attribute is set to 0, there is not a maximum time limit. The default is 0.
Parallel Connect Delay
The delay in seconds when making concurrent attempts to attempt to multiple LDAP servers. If this attribute is set to 0, connection attempts are serialized. An attempt is made to connect to the first server in the list. The next entry in the list is tried only if the attempt to connect to the current host fails. If this attribute is not set and an LDAP server is unavailable, an application may be blocked for a long time. If this attribute is greater than 0, another connection is started after the specified time.
For a more secure deployment, BEA recommends using the SSL protocol to protect communications between the LDAP server and WebLogic Server. For more information, see Configuring SSL
Locating Users in the LDAP Directory
To specify how users are located in the LDAP directory:
Click the Users tab under the Configuration tab for the LDAP server you chose.
For example, click the Users tab under the iPlanet Configuration tab.
Define information about how users are stored and located in the LDAP directory by defining values for the attributes shown on the Users tab.
The following table describes the attributes you set on the Users tab.
Table 3-4 Attributes on the Users Tab
Attribute
Description
User Object Class
The LDAP object class that stores users.
User Name Attribute
The attribute on an LDAP user object that specifies the name of the user.
User Dynamic Group DN Attribute
The attribute of an LDAP user object that specifies the distinguished name of dynamic groups to which this user belongs.
Dynamic groups are not supported with the Active Directory, Open LDAP, or Novell NDS directory servers, so set this attribute to NULL for these servers.
If this attribute does not exist, WebLogic Server looks at the Dynamic Group Object Class attribute to determine the groups to which this user belongs.
If a group contains other groups, WebLogic Server evaluates the URLs of any of the descendents of the group.
User Base DN
The base DN of the tree in the LDAP directory that contains users.
If you store WebLogic Server users under multiple roots in your directory, you can specify these roots as user.dn.1, user.dn.2, and so on. The LDAP Authentication provider will search under each of these roots in turn until it finds a matching user.
Note: You must supply a user.filter.n for each user.dn.n entry.
User Search Scope
Specifies how deep in the LDAP directory tree to search for users.
Valid values are subtree and onelevel.
User from Name Filter
An LDAP search filter for finding a user given the name of the user.
If a search filter is not specified (that is, if the attribute is null or empty), a default search filter is created based on the user schema.
Refer to the documentation for your LDAP server for more information about writing an LDAP search filter.
All Users Filter
An LDAP search filter for finding all users beneath the base DN. If a search filter is not specified (that is, if the attribute is null or empty), a default search filter is created based on the user schema.
Refer to the documentation for your LDAP server for more information about writing an LDAP search filter.
To define how groups are stored and located in the LDAP directory:
Click the Groups tab under the Configuration tab.
For example, click the Groups tab under the iPlanet Configuration tab.
Define information about how groups are stored and located in the LDAP directory by defining values for the attributes shown on the Groups tab.
The following table describes the attributes you set on the Groups tab.
Table 3-5 Attributes on the Groups Tab
Attribute
Description
Group Base DN
The base DN of the tree in the LDAP directory that stores groups.
Group Search Scope
Specifies how deep in the LDAP directory tree to search for groups.
Valid values are subtree and onelevel.
Group From Name Filter
An LDAP search filter for finding a group given the name of the group.
Refer to the documentation for your LDAP server for more information about writing an LDAP search filter.
All Groups Filter
An LDAP search filter for finding all groups beneath the base group DN. If the attribute is not specified (that is, if the attribute is null or empty), a default search filter is created based on the Group schema.
Refer to the documentation for your LDAP server for more information about writing an LDAP search filter.
Static Group Object Class
The name of the LDAP object class that stores static groups.
Static Group Name Attribute
The attribute of a static LDAP group object that specifies the name of the group.
Note: The iPlanet Authentication provider supports dynamic groups. To use dynamic groups, set the Dynamic Group Object Class, Dynamic Group Name Attribute, and Dynamic Member URL Attribute attributes.
To define how groups members are stored and located in the LDAP directory:
Click on the Membership tab under the Configuration tab.
For example, click the Membership tab under the iPlanet Configuration tab.
Define information about how group members are stored and located in the LDAP directory by defining values for the attributes shown on the Membership tab.
The following table describes the attributes you set on the Membership tab.
Table 3-6 Attributes on the Membership Tab
Attribute
Definition
Static Member DN Attribute
The attribute of an LDAP group object that specifies the DNs of the members of the group.
Static Group DNs from Member DN Filter
An LDAP search filter that, given the DN of a member of a group, returns the DNs of the static LDAP groups that contain that member.
If the attribute is not specified (that is, if the attribute is null or empty), a default search filter is created based on the group schema.
Refer to the documentation for your LDAP server for more information about writing an LDAP search filter.
Dynamic Group Object Class
The name of the LDAP object class that stores dynamic groups.
Dynamic groups are not currently supported by Active Directory, Open LDAP, or Novell NDS directory servers. Do not set this attribute if you are using these servers.
Dynamic Group Name Attribute
The attribute of a dynamic LDAP group object that specifies the name of the group.
Dynamic groups are not currently supported by Active Directory, Open LDAP, or Novell NDS directory servers. Do not set this attribute if you are using these servers.
Dynamic Member URL Attribute
The attribute of the dynamic LDAP group object that specifies the URLs of the members of the dynamic group.
Note: A Malformed URL exception can result when this attribute contains a string value with a reserved value. To avoid this exception, avoid using :, ,, ?, and / in the attribute.
Dynamic groups are not currently supported by Active Directory, Open LDAP, or Novell NDS directory servers. Do not set this attribute if you are using these servers.
Configuring Failover for LDAP Authentication Providers
In WebLogic Server 7.0 SP2 and greater, you can configure an external LDAP provider with multiple LDAP servers and enable failover if one LDAP server is not available.
To configure failover of the LDAP servers configured for an LDAP Authentication provider, perform the following steps:
Click the LDAP tab under the Configuration tab for the LDAP Authentication provider for which you want to configure failover.
For example, click the iPlanet LDAP tab under the iPlanet Configuration tab.
Click the LDAP tab.
Specify more than on LDAP server name in the Host attribute on the LDAP tab. The attribute must contain a space-delimited list of host names. Each host name may include a trailing colon and port number. For example:
The Parallel Connect Delay attribute specifies the number of seconds to delay when making concurrent attempts to connect to multiple servers. An attempt is made to connect to the first server in the list. The next entry in the list is tried only if the attempt to connect to the current host fails. This setting might cause your application to block for unacceptably long time if a host is down. If the attribute is set to a value greater than 0, another connection setup thread is started after the specified number of delay seconds has passed. If the attribute is set to 0, connection attempts are serialized.
Set the Connection Timeout attribute.
The Connection Timeout attribute specifies the maximum number of seconds to wait for the connection to the LDAP server to be established. If the attribute is set to 0, there is no maximum time limit and WebLogic Server will wait until the TCP/IP layer times out to return a connection failure. This attribute may be set to a value over 60 seconds depending upon the configuration of TCP/IP.
Click Apply.
Reboot WebLogic Server.
The following examples present use scenarios that will occur when the LDAP attributes are set for LDAP failover.
Example 1
When the LDAP attribute values are set to the following:
In this scenario, WebLogic Server will attempt to connect to directory.knowledge.com. After 10 seconds, the connect attempt will timeout and WebLogic Server will try the next host specified in the Host attribute (people.catalog.com). WebLogic Server will then use people.catalog.com as the LDAP Server for this connection.
Example 2
When the LDAP attribute values are set to the following:
In this scenario, WebLogic Server will attempt to connect to directory.knowledge.com. After 1 second, the connect attempt will timeout and WebLogic Server will try the next host specified in the Host attribute (people.catalog.com) and will try to connect to people.catalog.com in parallel. WebLogic Server will then use people.catalog.com as the LDAP Server for this connection.WebLogic Server will cancel the connect to directory.knowledge.com after the connect to people.catalog.com succeeds.
Configuring a WebLogic Authentication Provider
Note: The WebLogic Server Administration Console refers to the WebLogic Authentication provider as the Default Authenticator.
The WebLogic Authentication provider is case insensitive. Ensure user names are unique.
The WebLogic Authentication provider allows you to edit, list, and manage users and group membership. User and group membership information for the WebLogic Authentication provider is stored in the embedded LDAP server.
To configure the WebLogic Authentication provider:
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers-->Authentication Providers nodes.
The Authenticators table displays the name of the default Authentication and Identity Assertion providers.
Choose the Configure a new Default Authenticator... link.
Define values for the attributes on the General tab.
The Minimum Password Length attribute applies to the passwords you specify when defining users in the WebLogic Authentication provider.
The Control Flag attribute determines how the WebLogic Authentication provider is used with other Authentication providers. For more information, see Setting the JAAS Control Flag Attribute.
Click Apply to save your changes.
Define values for the attributes on the Details tab.
Group Membership Searching—Controls whether group searches are limited in depth or unlimited. This attribute controls how deeply a search should recursive into nested groups. For configurations that use only the first level of nested group hierarchy, this attribute allows improved performance during user searches by limiting the search to the first level of the group.
If a limited search is specified, the Max Group Membership Search Level attribute must be specified.
If an unlimited search is specified, the Max Group Membership Search Level attribute is ignored.
Max Group Membership Search Level—Controls the depth of a group membership search if the Group Membership Searching attribute is specified. Possible values are:
0—Indicates only direct groups will be found. That is, when searching for membership in Group A, only direct members of Group A will be found. If Group B is a member of Group A, the members will not be found by this search.
Any positive number—Indicates the number of levels to search. For example, if this attribute is set to 1, a search for membership in Group A will return direct members of Group A. If Group B is a member of Group A, the members of Group B will also be found by this search. However, if Group C is a member of Group B, the members of Group C will not be found by this search.
Configuring a Realm Adapter Authentication Provider
The Realm Adapter Authentication provider allows you to use users and groups from 6.x security realms in this release of WebLogic Server. Use the Realm Adapter Authentication provider if you store users and groups in the 6.x Windows NT, UNIX, RDBMS security realms or 6.x custom security realm. (There are no equivalents to the 6.x Windows NT, UNIX, RDBMS security realms in this release of WebLogic Server). A Realm Adapter Authentication provider can be configured instead of or in addition to the WebLogic Authentication provider.
When using Compatibility Security, a Realm Adapter Authentication provider is by default configured for the CompatibilityRealm. However, you can configure a Realm Adapter Authentication provider in any security realm. For information about using the Realm Adapter Authentication provider in the CompatibilityRealm, see The Default Security Configuration in the CompatibilityRealm.
The Realm Adapter Authentication provider also allows use of implementations of the weblogic.security.acl.CertAuthenticator class with this release of WebLogic Server. The Realm Adapter Authentication provider includes an Identity Assertion provider which provides identity assertion based on X.509 tokens. For information about using a CertAuthenticator with WebLogic Server, Configuring the Identity Assertion Provider in the Realm Adapter Authentication Provider.
When adding a Realm Adapter Authentication provider to a security realm with an Authentication provider already configured, the WebLogic Server Administration Console sets the Control Flag attribute on the Realm Adapter Authentication provider to OPTIONAL and checks for the presence of a fileRealm.properties file in the domain directory. The WebLogic Server Administration Console will not add the Realm Adapter Authentication provider to the security realm if the fileRealm.properties file does not exist.
Note: The subjects produced by the Realm Adapter Authentication provider do not contain principals for the groups to which a user belongs. Use the weblogic.security.SubjectUtils.isUserInGroup() method to determine whether a user is in a group. When using subjects produced by the Realm Adapter Authentication provider there is no way to iterate the complete set of groups to which a user belongs.
To define attributes for the Realm Adapter Authentication provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers-->Authentication Providers nodes.
The Authenticators table displays the name of the default Authentication and Identity Assertion providers.
Choose the Configure a new Realm Adapter Authenticator... link.
Set the Control Flag attribute on the General tab. The Control Flag attribute determines how the Realm Adapter Authentication provider is used with other Authentication providers. See Setting the JAAS Control Flag Attribute.
Click Apply to save your changes.
Reboot WebLogic Server.
Optionally, configure the Identity Assertion provider in the Realm Adapter Authentication provider to use implementations of the weblogic.security.acl.CertAuthenticator class with this release of WebLogic Server. The Identity Assertion provider uses X.509 tokens to perform identity assertion.
Configuring a WebLogic Identity Assertion Provider
Note: The WebLogic Server Administration Console refers to the WebLogic Identity Assertion provider as the Default Identity Asserter.
If you are using perimeter authentication, you need to use an Identity Assertion provider. In perimeter authentication, a system outside of WebLogic Server establishes trust via tokens (as opposed to simple authentication, where WebLogic Server establishes trust via usernames and passwords). An Identity Assertion provider verifies the tokens and performs whatever actions are necessary to establish validity and trust in the token. Each Identity Assertion provider is designed to support one or more token formats.
You can use either a WebLogic Identity Assertion provider or a custom Identity Assertion provider in a security realm. This section describes how to configure a WebLogic Identity Assertion provider. For information about configuring a custom security provider (including a custom Identity Assertion provider), see Configuring a Custom Security Provider
Multiple Identity Assertion providers can be configured in a security realm, but none are required. Identity Assertion providers can support more than one token type, but only one token type per Identity Assertion provider can be active at a given time. When using the WebLogic Identity Assertion provider, configure the active token type. The WebLogic Identity Assertion provider supports identity assertion using X509 certificates and CORBA Common Secure Interoperability version 2 (CSI v2).
If multiple Identity Assertion providers are configured in a security realm, they can all support the same token type. However, one only provider in the security realm can have the token active.
When using the WebLogic Identity Assertion provider in a security realm, you also have the option of using a user name mapper to map the tokens authenticated by the Identity Assertion provider to a user in the security realm. For more information about configuring a user name mapper, see Using a User Name Mapper with the WebLogic Identity Assertion Provider.
To define attributes for the WebLogic Identity Assertion provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers-->Authentication Providers nodes.
The Authenticators table displays the name of the default Authentication and Identity Assertion providers.
Choose the Configure a new Default Identity Asserter... link from the Authenticators tab.
In the Trusted Client Principals attribute define the list of client principals that can use CSIv2 identity assertion. You can use an asterisk (*) to specify all client principals. This attribute is only required if you are using CSI v2 identity assertion.
Define the active token type for the WebLogic Identity Assertion provider. The list of token types supported by the Identity Assertion is displayed in the Supported Types attribute. Type the name of one of the supported token types in the Active Types attribute.
Click Apply to save your changes.
Click the Details tab.
Verify the setting of the Base64 Decoding Required attribute.
If the authentication type in a Web application is set to CLIENT-CERT, the Web Application Container in WebLogic Server performs identity assertion on values from request headers and cookies. If the header name or cookie name matches the active token type for the configured Identity Assertion provider, the value is passed to the provider.
The Base64 Decoding Required attribute determines whether the request header value or cookie value must be Base64 Decoded before sending it to the Identity Assertion provider. The setting is enabled by default for purposes of backward compatibility, however, most Identity Assertion providers will disable this attribute.
Using a User Name Mapper with the WebLogic Identity Assertion Provider
When using 2-way SSL, WebLogic Server verifies the digital certificate of the Web browser or Java client when establishing an SSL connection. However, the digital certificate does not identify the Web browser or Java client as a user in the WebLogic Server security realm. If the Web browser or Java client requests a WebLogic Server resource protected by a security policy, WebLogic Server requires the Web browser or Java client to have an identity. The WebLogic Identity Assertion provider allows you to enable a user name mapper that maps the digital certificate of a Web browser or Java client to a user in a WebLogic Server security realm.
The user name mapper must be an implementation the weblogic.security.providers.authentication.UserNameMapper interface. This interface maps a token to a WebLogic Server user name according to whatever scheme is appropriate for your needs. You can also use this interface to map from an X.501 distinguished name to a user name.
To use a user name mapper with the WebLogic Identity Assertion provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers-->Authentication Providers nodes.
Choose the Default Identity Assertion provider.
The General tab appears.
Enter the name of your implementation of the weblogic.security.providers.authentication.UserNameMapper interface in the User Name Mapper Class Name attribute.
The implementation of the weblogic.security.providers.authentication.UserNameMapper interface must be specified in your CLASSPATH.
Click Apply.
Reboot WebLogic Server.
Configuring an LDAP X509 Identity Assertion Provider
Note: The configuration of the functionality offered in the LDAP X509 Identity Assertion provider will change in future releases of WebLogic Server. This version of the LDAP X509 Identity Assertion provider is not upward compatible with future releases of WebLogic Server. In addition, the provider has only been tested with the Sun One LDAP server. For information about the usability of the LDAP X509 Identity Assertion provider, see the WebLogic Server Release Notes.
The LDAP X509 Identity Assertion provider receives an X509 certificate, looks up the LDAP object for the user associated with that certificate, ensures that the certificate in the LDAP object matches the presented certificate, and then retrieves the name of the user from the LDAP object.
The LDAP X509 Identity Assertion provider works in the following manner:
An application needs to be set up to use perimeter authentication (in other words, users or system process use tokens to assert their identity). As part of the SSL handshake, the application presents it certificate. The Subject DN in the certificate can be used to locate the object that represents the user in the LDAP server. The object contains the user's certificate and name.
The LDAP X509 Identity Assertion provider uses the certificate in the Subject DN to construct an LDAP search to find the LDAP object for the user in the LDAP server. It gets the certificate from that object, ensures it matches the certificate it holds, and retrieves the name of the user.
The username is passed to the authentication providers configured in the security realm. The authentication providers ensure the user exists and locates the groups to which the user belongs.
Typically, if you use the LDAP X509 Identity Assertion provider, you will also need to configure an LDAP Authentication provider that uses an LDAP server. The authentication provider ensures the user exists and locates the groups to which the user belongs. You should ensure both providers are properly configured to communicate with the same LDAP server.
Using an LDAP X509 Identity Assertion provider involves:
Obtaining certificates for users and putting them in an LDAP Server. There must be a correlation between the Subject DN in the certificate and the location of the object for that user in the LDAP server. The LDAP object for the user must also include attributes for the certificate and the username that will be used in the Subject.
Configuring the LDAP X509 Identity Assertion provider to find the LDAP object for the user in the LDAP directory given the certificate's Subject DN. Basically, the user's DN in LDAP and/or the LDAP object for the user must contain attributes that match values in the certificate's Subject DN.
Example 1: LDAP object matches Subject DN attribute.
Configuring the LDAP X509 Identity Assertion provider to search the LDAP server to locate the LDAP object for the user. This requires the following pieces of data.
A base LDAP DN from which to start searching. The Certificate Mapping attribute for the LDAP X509 Identity Assertion provider tells the identity assertion provider how to construct the base LDAP DN from the certificate's Subject DN. The LDAP object must contain an attribute the holds the certificate.
A search filter that only returns LDAP objects that match a defined set of attributes. The filter narrows the LDAP search. Configure the User Filter Search attribute to construct a search filter from the certificate's Subject DN.
Where in the LDAP directory to search for the base LDAP DN. The LDAP X509 Identity Assertion provider searches recursively (one level down). This attribute must match the values of the attributes in the certificate's Subject DN.
Configuring the Certificate attribute of the LDAP X509 Identity Assertion provider to specify which attribute of the LDAP object for the user holds the certificate. The LDAP object must contain an attribute the holds the certificate.
Configuring the Username attribute of the LDAP X509 Identity Assertion provider to specify which of the LDAP object's attributes holds the username that should appear in the Subject DN.
Configuring the LDAP server connection for the LDAP X509 Identity Assertion provider. The LDAP server attribute information should be the same as the information defined for the LDAP Authentication provider configured in this security realm.
Configuring an LDAP Authentication provider for use with the LDAP X509 Identity Assertion provider. The LDAP server attribute information should be the same the information defined for the LDAP X509 Identity Assertion provider configured in Step 6.
To define attributes for the LDAP X509 Identity Assertion provider:
Expand the Security-->Realms nodes.
Select the name of the realm you are configuring (for example, TestRealm).
Expand the Providers-->Authentication Providers nodes.
The Authenticators table displays the name of the default Authentication and Identity Assertion providers.
On the Authenticators tab, click the Configure a new LDAP X509 Identity Asserter... link.
The General tab appears.
Define name and token information for the LDAP X509 Identity Assertion provider.
The following table lists the attributes you set on the General tab.
Table 3-7 Attributes on the General Tab
Attribute
Description
Name
The name of this LDAP X509 Identity Assertion provider.
Description
A short description of this LDAP X509 Identity Assertion provider.
Version
The version number of this LDAP X509Identity Assertion provider.
Supported Types
The supported token types of this LDAP X509 Identity Assertion provider. This attribute is always set to X509.
Active Types
The token type this LDAP X509 Identity Assertion provider uses for authentication. This token type is always set to X509.
Ensure no other identity assertion provider configured in the same security realm has this attribute set to X509.
Click Apply to save your changes.
Select the Details tab.
Define information about the attributes used to map the username in the LDAP directory to the username the certificate and the LDAP server to be used by the LDAP X509 Identity Assertion provider.
The following table describes the attributes you set on the Details tab.
Note: $subj indicates the Subject attribute in the certificate. For example: CN=meyer.beasys.com, ou=CCE, o=BEASYS, L=SFO, C=US.
Table 3-8 Attributes on the Details Tab
Attribute
Definition
Certificate Mapping
Specifies how to construct the base LDAP DN used to locate the LDAP object for the user. This attribute defines how to find the object from the certificate's Subject DN.
Typically, this value is the same as the User Base DN attribute in the LDAP Authentication providers. You may include the fields from the Subject DN in this base DN.
For example: if the Certificate subject is CN=meyer.beasys.com, ou=fred, o=BEASYS, L=SFO, C=US and the mapping is ou=people, ou=$subj.ou, WebLogic Server uses ou=people, ou=fred, o=BEASYS, c=US as the DN when locating the user.
User Filter Attributes
Specifies how to select the LDAP object for the user from the LDAP objects beneath the base LDAP DN defined in the Certificate Mapping attribute. This attribute defines how to find the LDAP object from the certificate's Subject DN.
The LDAP object's class must be person. This attribute contains an array of strings, each of which is an attribute that the LDAP object must match.
Typically, the value of this attribute is the LDAP object that matches the value of an attribute in the certificate's Subject DN.
For example:
The uid attribute of the LDAP user object matches the Subject DN attribute, if the syntax is:
LDAPATTRNAME=$subj.SUBJECDNATTRNAME
For example: uid=$subj.DN
This attribute is very similar to the User Name Filter attribute on LDAP Authentication providers which maps a username to a search filter. The differences are:
This attribute maps a certificate's Subject DN to a filter and the LDAP Authentication provider uses a single string giving the system administrator complete control over the filter.
The LDAP X509 Authentication provider adds objectclass=person to the filter and uses an array of strings that are combined.
Certificate Attribute
Specifies the attribute on the LDAP object for the user that contains the user's certificate. This attribute defines how to find the certificate. Valid values are userCertificate and userCertificate;binary. The default is userCertificate.
If you use the LDAP browser to load a certificate into the LDAP directory, an attribute userCertificate of type binary is created. To access the certificate, define the Certificate attribute as userCertificate.
If you use ldapmodify to create the new attribute (for example, using the following command):
An attribute userCertificate;binary is
created when the certificate data is loaded in the
LDAP directory. To access the certificate, define
the Certificate attribute as
userCertificate;binary.
Username Attribute
Specifies the attribute on the LDAP object for the user that contains the user's name. The user's name should appear in the Subject. This attribute defines how to find the user's name.
Typically, this attribute matches the User Name attribute of the LDAP Authentication provider.
Base64 Decoding Required
Determines whether the request header value or cookie value must be Base64 Decoded before sending it to the Identity Assertion provider. The setting is enabled by default for purposes of backward compatibility, however, most Identity Assertion providers will disable this attribute.
Host
The host name of the computer on which the LDAP server is running.
Port
The port number on which the LDAP server is listening. If you want WebLogic Server to connect to the LDAP server using the SSL protocol, use the LDAP server's SSL port in this attribute.
SSL Enabled
Option for enabling the SSL protocol to protect communications between the LDAP server and WebLogic Server. Disable this attribute if the LDAP server is not configured to use the SSL protocol.
Principal
The Distinguished name (DN) of the LDAP user used by WebLogic Server to connect to the LDAP server. Generally, this user is the system administrator of the LDAP directory server. If you want to change passwords, this attribute must be the system administrator.
Credential
Password that authenticates the LDAP user defined in the Principal attribute.
Cache Enabled
Enables the use of a data cache with the LDAP server.
Cache Size
Maximum size of lookups in cache. The default is 32kb.
Cache TTL
Number of seconds to retain the results of an LDAP lookup.
Follow Referrals
Specifies that a search for a user or group within the LDAP X509 Identity Assertion provider will follow referrals to other LDAP servers or branches within the LDAP directory. By default, this attribute is enabled.
Bind Anonymously On Referrals
By default, the LDAP X509 Identity Assertion provider uses the same DN and password used to connect to the LDAP server when following referrals during a search. If you want to connect as an anonymous user, enable this attribute. Contact your LDAP system administrator for more information.
Results Time Limit
The maximum number of milliseconds for the LDAP server to wait for results before timing out. If this attribute is set to 0, there is not maximum time limit. The default is 0.
Connect Timeout
The maximum time in seconds to wait for the connection to the LDAP server to be established. If this attribute is set to 0, there is not a maximum time limit. The default is 0.
Parallel Connect Delay
The delay in seconds when making concurrent attempts to attempt to multiple LDAP servers. If this attribute is set to 0, connection attempts are serialized. An attempt is made to connect to the first server in the list. The next entry in the list is tried only if the attempt to connect to the current host fails. If this attribute is not set and an LDAP server is unavailable, an application may be blocked for a long time. If this attribute is greater than 0, another connection is started after the specified time.
When an HTTP request is sent, there may be multiple matches that can be used for identity assertion. Identity assertion in WebLogic Server uses the following ordering:
An X.590 digital certificate (signifies two-way SSL to client or proxy plug-in with two-way SSL between the client and the Web server) if X.509 is one of the active token types configured for the Identity Assertion provider in the default security realm.
Headers with a name in the form WL-Proxy-Client-<TOKEN> where <TOKEN> is one of the active token types configured for the Identity Assertion provider in the default security realm.
Note: This method is deprecated and should only be used for the purpose of backward compatibility.
Headers with a name in the form <TOKEN> where <TOKEN> is one of the active tokens types configured for the Identity Assertion provider in the default security realm.
Cookies with a name in the form <TOKEN> where <TOKEN> is one of the active tokens types configured for the Identity Assertion provider in the default security realm.
For example, if an Identity Assertion provider in the default security realm is configured to have the FOO and BAR tokens as active token types (for the following example, assume the HTTP request contains nothing relevant to identity assertion except active token types), identity assertion is performed as follows:
If a request comes in with a FOO header over a two-way SSL connection then X.509 is used for identity assertion.
If a request comes in with a FOO header and a WL-Proxy-Client-BAR header then the BAR token is used for identity assertion.
If a request comes in with a FOO header and a BAR cookie then the FOO token will be used for identity assertion.
The ordering between multiple tokens at the same level is undefined, therefore:
If a request comes in with a FOO header and a BAR header, then either the FOO or BAR token is used for identity assertion, however, which one is used is unspecified.
If a request comes in with a FOO cookie and a BAR cookie, then either the FOO or BAR token is used for identity assertion, however, which one is used is unspecified.
Configuring a WebLogic Authorization Provider
Authorization is the process whereby the interactions between users and resources are limited to ensure integrity, confidentiality, and availability. In other words, authorization is responsible for controlling access to resources based on user identity or other information.
You can use either a WebLogic Authorization provider or a custom Authorization provider in a security realm. This section describes how to configure a WebLogic Authorization provider. For information about configuring a custom security provider (including a custom Authorization provider), see Configuring a Custom Security Provider
To configure a WebLogic Authorization provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers node.
Click Authorizers.
The Authorizers table displays the name of the default Authorization provider for the realm that is being configured.
Click the Configure a new Default Authorizer... link.
Define values for the attributes on the General tab.
The Policy Deployment Enabled attribute specifies whether or not this Authorization provider stores policy information (as opposed to retrieving policy information) for the security realm. In order to support the Policy Deployment Enabled attribute, an Authorization provider must implement the DeployableAuthorizationProvider Security Service Provider Interface (SSPI). By default, the WebLogic Authorization provider has this attribute enabled. The policy information is stored in the embedded LDAP server.
Click Apply to save your changes.
Reboot WebLogic Server.
Configuring a WebLogic Credential Mapping Provider
Credential mapping is the process whereby the authentication and authorization mechanisms of a remote system (for example, a legacy system or application) are used to obtain an appropriate set of credentials to authenticate users to a target WebLogic resource.
You can use either a WebLogic Credential Mapping provider or a custom Credential Mapping provider in a security realm. This section describes how to configure a WebLogic Credential Mapping provider. For information about configuring a custom security provider (including a custom Credential Mapping provider), see Configuring a Custom Security Provider
To configure a WebLogic Credential Mapping provider:
Expand the Security-->Realms nodes.
Click the name of the realm you are configuring (for example, TestRealm).
Expand the Providers node.
Click Credential Mappers.
Click the Configure a new Default Credential Mapper... link.
On the General tab, set the Credential Mapping Deployment Enabled attribute.
The Credential Mapping Deployment Enabled attribute specifies whether or not this Credential Mapping provider imports credential maps from deployment descriptors (weblogic-ra.xml files) into the security realm. In order to support the Credential Mapping Deployment Enabled attribute, a Credential Mapping provider must implement the DeployableCredentialProvider SSPI. By default, the WebLogic Credential Mapping provider has this attribute enabled. The credential mapping information is stored in the embedded LDAP server.
A keystore is a mechanism designed to create and manage files that store private keys and trusted certificate authorities (CAs). The WebLogic Keystore provider locates instances of keystores. Configuring a WebLogic Keystore provider is one of the options you have when setting up the SSL protocol. For more information, see Storing Private Keys, Digital Certificates, and Trusted Certificate Authorities. Configuring the WebLogic Keystore is an optional step when customizing a security realm or creating a new security realm.
Configuring a WebLogic Role Mapping Provider
Role Mapping providers compute the set of roles granted to a subject for a given resource. Role Mapping providers supply Authorization providers with this role information so that the Authorization Provider can answer the "is access allowed?" question for WebLogic resources.
You can use either a WebLogic Role Mapping provider or a custom Role Mapping provider in a security realm. This topic describes how to configure a WebLogic Role Mapping provider. For information about configuring a custom security provider (including a custom Role Mapping provider), see Configuring a Custom Security Provider
To configure an Role Mapping provider:
Expand the Security node.
Expand the Realms node.
Click the name of the realm you are configuring (for example, TestRealm).
Click the Providers node.
Click Role Mappers.
The Role Mappers table appears. This table displays the name of the default Role Mapping provider for the realm that is being configured.
Click the Configure a new Default Role Mapper... link.
The General tab appears.
Define values for the attributes on the General tab.
The Role Mapping Deployment Enabled attribute specifies whether or not this Role Mapping provider imports information from deployment descriptors for Web applications and EJBs into the security realm. In order to support the Role Mapping Deployment Enabled attribute, a Role Mapping provider must implement the DeployableRoleProvider SSPI. By default, the WebLogic Role Mapping provider has this attribute enabled. Roles are stored in the embedded LDAP server.
Put the MBean JAR file for the provider in the WL_HOME\lib\mbeantypes directory.
Start the WebLogic Server Administration Console.
Expand the Security-->Realms nodes.
Click on the name of the realm you are configuring (for example, TestRealm.)
Expand the Providers node.
Expand the node for the type of provider you are configuring. For example, expand the Authenticator node to configure a custom Authentication provider.
The tab for the provider appears.
Click the Configure a new custom Security_Provider_Type... link
where Security_Provider_Type is the name of your custom security provider. This name is read from the DisplayName attribute in the MBeanType tag of the MBean Definition File (MDF).
The General tab appears.
The Name attribute displays the name of your custom Security provider.
If desired, adjust the values for the attributes for the custom Security provider.
Click Apply to save your changes.
Reboot WebLogic Server.
Deleting a Security Provider
To delete a security provider:
Expand the Security-->Realms nodes.
Click the name of the realm in which the provider you want to delete is configured (for example, TestRealm).
Expand the Providers node.
Click the type of provider you want to delete (for example, TestRealm-->Authorizers).
The table page for the provider appears (for example, the Authorizers table). The table page for the provider displays the names of all the configured providers.
To delete a provider, click on the trash can icon in the provider table.
Reboot WebLogic Server.
Note: Deleting and modifying configured security providers by using the WebLogic Server Administration Console may require manual clean up of the security provider database.
