Configure Security Providers

 

  1. When Do I Need to Configure a Security Provider?
  2. Configure a WebLogic Adjudication Provider
  3. Configure a WebLogic Auditing Provider
  4. Choose an Authentication Provider
  5. Configure an Authentication Provider: Main Steps
  6. Set the JAAS Control Flag Attribute
  7. Configure an LDAP Authentication Provider
  8. Configure a WebLogic Authentication Provider
  9. Configure a Realm Adapter Authentication Provider
  10. Configure a WebLogic Identity Assertion Provider
  11. Changing the Order of Authentication Providers
  12. Configure a User Name Mapper
  13. Configure a Custom User Name Mapper
  14. Configure a WebLogic Authorization Provider
  15. Configure a WebLogic Credential Mapping Provider
  16. Configure a WebLogic Keystore Provider
  17. Configure a WebLogic Role Mapping Provider
  18. Configure a Custom Security Provider
  19. Delete a Security Provider

Note that only the Realm Adapter Auditing, Adjudication, and Authorization providers are available when you are using Compatibility Security.

 


When Do I Need to Configure a Security Provider?

By default, most configuration work for WebLogic security providers is done. However, the following circumstances require you to configure attributes on a security provider:

  • Before using the WebLogic Identity Assertion provider, define the active token type.

  • To map tokens to a user in a security realm, configure the user name mapper in the WebLogic Identity Assertion provider.

  • To use auditing in the default (active) security realm, configure either the WebLogic Auditing provider or a custom Auditing provider.

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

  • 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) in myrealm, configure the Realm Adapter Authentication provider. The Realm Adapter Authentication provider can be used instead of or in addition to the WebLogic Authentication provider. Note that 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.

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

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 requires an Adjudication provider. 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.

To configure a WebLogic Adjudication provider:

  1. In the left pane of the WebLogic Server Administration Console, expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm.)

  3. Expand the Providers node.

  4. Click Adjudicators.

    The Adjudicators table displays the name of the default Adjudication provider for the realm that is being configured.

  5. Click the Configure a new Default Adjudicator... link.

    When working in an existing security realm, click the Replace with a new Default Adjudicator... link.

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

  7. Click Apply to save your changes.

  8. 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. Configure 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.

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:

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers node.

  4. Click Auditors.

    The Auditors table displays the name of the default Auditor for the realm that is being configured.

  5. Click the Configure a new Default Auditor... link.

  6. On the General tab, 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

  7. Click Create to save your changes.

  8. 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:

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.

 


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, choose a pre-defined LDAP provider and customize it.

  • The Realm Adapter Authentication provider accesses user and group information stored in 6.x security realms.

  • The MedRec Authentication provider implements authentication for the MedRec sample application. This Authentication provider can only be used with the MedRec sample application and should be removed from production domains.

  • 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 that 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. Use the JAAS Control Flag attribute to set up login dependencies between Authentication providers and allow single-sign on between providers.

Authentication providers are called in the order in which they are configured. Therefore, use caution when configuring Authentication providers. Use the Reorder the Configured Authentication Providers link to modify the configuraiton of the Authentication providers.

 


Configuring an Authentication Provider: Main Steps

To configure an Authentication provider:

  1. Go to...

    Security | Realms | realm_name | Providers | Authentication Providers

    The Authenticators table displays the name of the default Authentication and Identity Assertion providers.

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

  3. Go to the appropriate sections to configure an Authentication and/or Identity Assertion provider.

  4. Repeat these steps to configure additional Authentication and/or Identity Assertion providers.

  5. If you are configuring multiple Authentication providers, set the JAAS control flag.

  6. After you finish configuring Authentication and/or Identity Assertion providers, reboot WebLogic Server.

 


Set 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 providers 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 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 or fail the authentication test of this 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 configured providers.

When additional Authentication providers are added to an existing security realm, by default the Control Flag attribute is set to OPTIONAL. If necessary, change the setting of the Control Flag so that the Authentication provider works properly in the authentication sequence. Note that 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:

  • Netscape iPlanet version 4.1.3
  • Active Directory shipped as part of Windows 2000
  • Open LDAP version 2.0.7
  • Novell NDS version 8.5.1

For more information, see:

 

Requirements for Using an LDAP Authentication Provider

If an LDAP Authentication provider is the only configured Authentication provider for a security realm, 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 who will boot WebLogic Server is included in the group.

    The Active Directory LDAP directory has a default group called Administrators. Add the user who 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.

 

Configure a LDAP Authentication Provider

To configure an LDAP Authentication provider:

  1. In the left pane of the WebLogic Server Administration Console, expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

    The Authenticators table displays the name of the default Authentication and Identity Assertion providers.

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

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

  6. Click Apply to save your changes.

  7. Proceed to Set LDAP Server and Caching Information.

 

Set LDAP Server and Caching Information

To configure the LDAP server:

  1. Select the Configuration-->LDAP tab for the LDAP Authentication provider you want to use.

    For example, select the iPlanet Configuration-->iPlanet tab.

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

    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.

  3. To save your changes, click Apply.

  4. Select 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.

    Attribute

    Description

    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.

  5. Proceed to Locating Users in the LDAP Directory.

For a more secure deployment, BEA recommends using the SSL protocol to protect communications between the LDAP server and WebLogic Server.

 

Locating Users in the LDAP Directory

To specify how users are located in the LDAP directory:

  1. Select the Configuration-->Users tab for the LDAP server you chose.

    For example, select the iPlanet Configuration-->Users tab.

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

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

  3. To save your changes, click Apply.
  4. Proceed to Locating Groups in the LDAP Directory.

 

Locating Groups in the LDAP Directory

To define how groups are stored and located in the LDAP directory:

  1. Select the Configuration-->Groups tab.

    For example, select the iPlanet Configuration-->Groups tab.

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

    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.

  3. To save your changes, click Apply.

  4. Proceed to Locating Members of a Group in the LDAP Directory.

 

Locating Members of a Group in the LDAP Directory

Note that 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:

  1. Select on the Configuration-->Membership tab.

    For example, select the iPlanet Configuration-->Membership tab.

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

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

  3. To save your changes, click Apply.
  4. Optionally, configure additional Authentication and/or Identity Assertion providers.
  5. Reboot WebLogic Server.

 

Accessing Other LDAP Servers

The LDAP Authentication providers in this release of WebLogic Server work with the iPlanet, Active Directory, Open LDAP, and Novell NDS LDAP Servers. You can use an LDAP Authentication provider to access new types of LDAP Servers. Choose the existing LDAP provider that most closely matches the new LDAP server and customize the existing attributes for the new LDAP server.

To create an LDAP Authentication provider for new LDAP server:

  1. In the left pane of the WebLogic Server Administration Console, expand the Security-->Realms nodes.
  2. Select the name of the realm you are configuring (for example, TestRealm).
  3. Expand the Providers-->Authentication Providers nodes.

    The Authenticators table displays the name of the default Authentication and Identity Assertion providers.

  4. Choose the LDAP Authentication provider that is most like the new LDAP server.

  5. On the General tab, enter a name for the new LDAP Authentication provider in the Name attribute (for example, MyLdapServer).

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

  7. Click Create.

  8. Select the LDAP Server tab (for example, iPlanet LDAP).

  9. Enable communication between WebLogic Server and the new LDAP server by modifying values for the attributes shown on the LDAP tab.

  10. Select the Users tab and define how users are located in the LDAP directory. Modify the existing values to match the values for the new LDAP server.

  11. Select the Groups tab and define how groups are located in the LDAP directory. Modify the existing values to match the values for the new LDAP server.

  12. Select the Membership tab and define how members of a group are located in the LDAP directory. Modify the existing values to match the values for the new LDAP server.

  13. Reboot WebLogic Server.

 

Configure Failover for LDAP Authentication Providers

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:

  1. Select the Configuration-->LDAP tab for the LDAP Authentication provider for which you want to configure failover.

    For example, select the iPlanet Configuration-->iPlanet tab.

  2. Select the LDAP tab.

  3. Specify more than one 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:

    directory.knowledge.com:1050 people.catalog.com 199.254.1.2

  4. Click Apply.

  5. Select the Details tab.

  6. Set the Parallel Connect Delay attribute.

    Specify 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 an 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.

  7. Set the Connection Timeout attribute.

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

  8. Click Apply.

  9. Reboot WebLogic Server.

The following examples present use scenarios that will occur when the LDAP attributes are set for LDAP failover.

Example 1

LDAP Attribute

Value

Host directory.knowledge.com:1050 people.catalog.com 199.254.1.2

The LDAP servers are working as follows:

directory.knowledge.com:1050 is down

people.catalog.com is up

199.254.1.2 is up

Parallel Connect Delay 0
Connect Timeout 10

In the preceeding scenario, WebLogic Server attempts to connect to directory.knowledge.com. After 10 seconds, the connect attempt times out and WebLogic Server attempts to connect to the next host specified in the Host attribute (people.catalog.com). WebLogic Server then uses people.catalog.com as the LDAP Server for this connection.

Example 2

LDAP Attribute

Value

Host directory.knowledge.com:1050 people.catalog.com 199.254.1.2

The LDAP servers are working as follows:

directory.knowledge.com:1050 is down

people.catalog.com is up

199.254.1.2 is up

Parallel Connect Delay 1
Connect Timeout 10

In the preceeding scenario, WebLogic Server attempts to connect to directory.knowledge.com. After 1 second, the connect attempt times out and WebLogic Server tries to connect to the next host specified in the Host attribute (people.catalog.com) and directory.knowledge.com in parallel. If the connection to people.catalog.com succeeds, WebLogic Server uses people.catalog.com as the LDAP Server for this connection.WebLogic Server cancels the connect to directory.knowledge.com after the connection to people.catalog.com succeeds.

 


Configuring a WebLogic Authentication Provider

Note that 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:

  1. Configure the embedded LDAP server as described in Managing the Embedded LDAP Server.

  2. Expand the Security-->Realms nodes.

  3. Select the name of the realm you are configuring (for example, TestRealm).

  4. Expand the Providers-->Authentication Providers nodes.

    The Authenticators table displays the name of the default Authentication and Identity Assertion providers.

  5. Choose the Configure a new Default Authenticator... link.

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

  7. Click Apply to save your changes.

  8. Optionally, configure additional Authentication and/or Identity Assertion providers.

  9. Reboot WebLogic Server.

 


Configuring a Realm Adapter Authentication Provider

The Realm Adapter Authentication provider allows you to use users and groups from 6.x security realms with the 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.

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.

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

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

    The Authenticators table displays the name of the default Authentication and Identity Assertion providers.

  4. Click the Configure a new Realm Adapter Authenticator... link.

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

  6. Click Apply to save your changes.

  7. Reboot WebLogic Server.

    After you reboot, the Compatibility Security tab appears and you have access to the pages in the WebLogic Server Administration Console used to manage the 6.x security realms. Note that you are not running Compatibility security.

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

    Set the Active Type for the Identity Asserter in the Realm Adapter Authentication provider.

    1. In the Available list box, click X.509 to highlight it.

    2. Click the right arrow to move X.509 to the Chosen list box.

  9. Click Apply to save your changes.

  10. Reboot WebLogic Server.

  11. Optionally, configure additional Authentication and/or Identity Assertion providers.

  12. Reboot WebLogic Server.

 


Configuring a WebLogic Identity Assertion Provider

Note that 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.

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.

To define attributes for the WebLogic Identity Assertion provider:

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

    The Authenticators table displays the name of the default Authentication and Identity Assertion providers.

  4. On the Authenticators tab, click the Configure a new Default Identity Asserter... link.

    The General tab appears.

  5. Configure a user name mapper.

  6. In the Trusted Client Principals attribute define the list of client principals that can use CSI v2 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.

  7. Set the Active Type for the WebLogic Identity Assertion provider. The list of token types supported by the WebLogic Identity Assertion provider is displayed in the Available list box. To set the Active Type:

    1. In the Available list box, select the desired token type.

    2. Click the right arrow to move the token type to the Chosen list box.

  8. Click Apply to save your changes.

  9. Select the Details tab.

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

  11. Click Apply.

  12. Optionally, configure additional Authentication and/or Identity Assertion providers.

  13. Reboot WebLogic Server.

 

Configure Identity Assertion Performance in the Server Cache

When using an Identity Assertion provider (either for an X.509 certificate or some other type of token), Subjects (a grouping of related information for a single entity including an identity and its security-related attributes) are cached within the server. This greatly enhances performance for servlets and EJB methods with <run-as> tags as well as for other places where identity assertion is used but not cached in the HTTPSession (for example, signing and encrypting XML documents).

Note: Caching can violate the desired semantics.

You can change the lifetime of items in this cache by setting the maximum number of seconds a Subject can live in the cache via the -Dweblogic.security.identityAssertionTTL command-line argument. The default for this command-line argument is 300 seconds (that is, 5 minutes). Set the value to zero disables the cache.

To improve the performance of identity assertion, specify a higher value for this command-line argument. Note that as identity assertion performance improves, the Identity Assertion provider is less responsive to changes in the configured Authentication provider. For example, a change in the user's group will not be reflected until the Subject is flushed from the cache and recreated. Set a lower value for the command-line argument makes authentication changes more responsive at a cost for performance.

 


Changing the Order of Authentication Providers

The way you configure multiple Authentication providers can affect the overall outcome of the authentication process, which is especially important for multipart authentication. Authentication providers are called in the order in which they are configured. The Authentication Providers table lists the authentication providers in the order they were configured. Click the Re-order the Configured Authentication Providers... link to change the order of the providers. Be aware that the way each Authentication provider's Control Flag attribute is set affects the outcome of the authentication process.

To change the ordering of Authentication providers:

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Click the Re-order the Configured Authentication Providers... link.

  5. Select an Authentication provider from the list of configured Authentication providers to highlight it.

  6. Use the arrow buttons to move the Authentication provider up or down in the list.

  7. Click Apply to save your changes.

  8. Reboot WebLogic Server.

 


Configure a User Name Mapper

WebLogic Server verifies the digital certificate of the Web browser or Java client when establishing a two-way 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 of 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. By default, WebLogic Server provides a default implementation of the weblogic.security.providers.authentication.UserNameMapper interface. You can also write your own implementation.

The WebLogic Identity Assertion provider calls the user name mapper for the following types of identity assertion token types:

The default user name mapper uses the attributes from the subject DN of the digital certificate or the distinguished name to map to the appropriate user in the WebLogic Server security realm. For example, the user name mapper can be configured to map a user from the Email attribute of the subject DN (smith@bea.com) to a user in the WebLogic Server security realm (smith).

To use the default user name mapper:

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Select the Default Identity Assertion provider.

  5. Select the Details tab.

  6. Check the Use the Default User Name Mapper attribute to enable the user name mapper.

  7. Specify the following attributes:

    • Default User Name Mapper Attribute Type - The attribute of the subject distinguished name (DN) in a digital certificate used to create a username. Valid values are: C, CN, E, L, O, and OU.

    • Default User Name Mapper Attribute Delimiter - The attribute that ends the username. The user name mapper uses everything to the left of the attribute to create a username.

  8. Click Apply.

  9. Reboot WebLogic Server.

 


Configure a Custom User Name Mapper

You can also write a custom user name mapper to map a token to a WebLogic Server user name according to whatever scheme is appropriate for your needs. The custom user name mapper must be an implementation of the weblogic.security.providers.authentication.UserNameMapper interface.

To install a custom user name mapper:

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Select the Default Identity Assertion provider.

  5. Select the General tab.

  6. Enter the class name of the implementation of the weblogic.security.providers.authentication.UserNameMapper interface in the User Name Mapper Class Name attribute.

  7. Click Apply.

  8. Reboot WebLogic Server.

 


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.

To configure a WebLogic Authorization provider:

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers node.

  4. Click Authorizers.

    The Authorizers table displays the name of the default Authorization provider for the realm that is being configured.

  5. Click the Configure a new Default Authorizer... link.

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

  7. Click Apply to save your changes.

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

To configure a WebLogic Credential Mapping provider:

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers node.

  4. Select Credential Mappers.

  5. Click the Configure a new Default Credential Mapper... link.

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

  7. Click Apply to save your changes.

  8. Reboot WebLogic Server.

 


Configure a WebLogic Keystore Provider

Note that the WebLogic Keystore provider is deprecated in this release of WebLogic Server. It is only supported for backward compatibility.

 


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.

To configure an Role Mapping provider:

  1. In the left pane of the WebLogic Server Administration Console. expand the Security-->Realms nodes.

  2. Select the name of the realm you are configuring (for example, TestRealm).

  3. Click the Providers node.

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

  5. Click the Configure a new Default Role Mapper... link.

    The General tab appears.

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

  7. Click Apply to save your changes.

  8. Reboot WebLogic Server.

 


Configuring a Custom Security Provider

To configure a custom security provider:

  1. Write a custom security provider.

    Put the MBean JAR file for the provider in...

    WL_HOME/lib/mbeantypes

  2. Start the WebLogic Server Administration Console.

  3. Expand the Security-->Realms nodes.

  4. Select the name of the realm you are configuring (for example, TestRealm.)

  5. Expand the Providers node.

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

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

  8. The General tab appears.

    The Name attribute displays the name of your custom Security provider.

  9. If desired, adjust the values for the attributes for the custom Security provider.

  10. Click Apply to save your changes.

  11. Reboot WebLogic Server.

 


Deleting a Security Provider

To delete a security provider:

  1. Expand the Security-->Realms nodes.

  2. Select the name of the realm in which the provider you want to delete is configured (for example, TestRealm).

  3. Expand the Providers node.

  4. Select the type of provider you want to delete (for example, TestRealm-->Authorizers).

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

  6. To delete a provider, click on the trash can icon in the provider table.

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

Skip navigation bar  Back to Top Previous Next