Customizing the Default Security Configuration

The following sections provide information and procedures for creating a new security realm.

 

---

Why Customize the Default Security Configuration?

Customize the default security configuration if you want to:

• Replace one of the WebLogic security providers with a custom security provider.
• Upgrade from Compatibility security to the security providers in WebLogic Server 7.0.
• Change the default attribute settings for a WebLogic Security provider.
• Configure additional security providers in the default security realm. (For example, if you want to use two Authentication providers, one that uses the embedded LDAP server and one that uses an existing store of users and groups.)
• Use an Authentication provider that accesses an LDAP server other than the embedded LDAP server.
• Use an existing store of users and groups instead of defining users and groups in the WebLogic Authentication provider.
• Add an Auditing provider to the default security realm.

The easiest way to customize the default security configuration is to modify the default security realm (myrealm) to contain the security providers you want. You can also customize the default security configuration by creating a new security realm, configuring security providers in that realm, and setting the new security realm as the default security realm. BEA recommends this process when upgrading a security configuration.

For example, if you are upgrading to the new security features in WebLogic Server 7.0, you may want to create a test security realm, configure security providers in the test security realm, and populate the security providers with security data (users, groups, roles, and security policies) for your application. Once the test security realm is working properly, you can set this test security realm as the default security realm.

For any security realm to be valid, you must configure each of the following types of security providers (in any order):

• Authentication
• Authorization
• Adjudication
• Credential Mapping
• Role Mapping

At least one Authorization, Credential Mapping, and Role Mapping provider in the security realm must implement the DeployableAuthorizationProvider, DeployableCredentialProvider, and DeployableRoleProvider Security Service Provider Interface (SSPI). This SSPI allows the providers to store (rather than retrieve) information from deployment descriptors.

For information about customizing the default security configuration, see:

• Configuring a Custom Security Provider [xref]
• Configuring the WebLogic Auditing provider [xref]
• Configuring an LDAP Authentication provider [xref]
• Configuring the Realm Adapter Authentication provider [xref]

 

---

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

Note: The Administration Console refers to the WebLogic Adjudication provider as the Default Adjudicator.

To configure a WebLogic Adjudication provider:

1. Expand the Security-->Realms nodes.
2. Click 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.
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. 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.

The Administration Console refers to the WebLogic Auditing provider as the Default Auditor.

To configure the WebLogic Auditing provider:

1. Expand the Security-->Realms nodes.
2. Click 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 Auditing provider for the realm that is being configured. By default, this table is empty.

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

   The General tab appears.

6. 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 (the default setting)
   • SUCCESS
   • FAILURE
   • none
7. Click Create to save your changes.
8. Reboot WebLogic Server.

The audit events generated by the WebLogic Auditing provider are saved in the DefaultAuditRecorder.log file, which is located in the bea_home\user_projects\domain directory (where bea_home represents the central support directory for all BEA products installed on one machine, and domain represents the name of the domain you create). 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.

 

 

---

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 allows you to manage users and groups in one place, 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.
• 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 maps a token to a username.

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

 

---

Configuring an Authentication Provider: Main Steps

To configure an Authentication provider:

1. Expand the Security-->Realms nodes.
2. Click 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 for the realm that is being configured.

4. Choose an Authentication and/or Identity Assertion provider by selecting the appropriate link:
   • Configure a new Active Directory Authenticator...
   • Configure a new Realm Adapter Authenticator...
   • Configure a new Novell Authenticator...
   • Configure a new iPlanet Authenticator...
   • Configure a new Default Authenticator...
   • Configure a new Default Identity Asserter...
   • Configure a new OpenLDAP Authenticator...
5. Go to the appropriate sections to configure an Authentication and/or Identity Assertion provider.
   • [xref]
6. Repeat these steps to configure additional Authentication and/or Identity Assertion providers.

   If you are configuring multiple Authentication providers, refer to [xref to JAAS].

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

 

---

Setting the JAAS Control Flag Attribute

If a security realm has multiple Authentication providers configured, the Control Flag attribute on the Authenticator-->General tab determines the ordered execution of the Authentication providers. The values for the Control Flag attribute are as follows:

• REQUIRED—This LoginModule must succeed. Even if it fails, authentication proceeds down the list of LoginModules for the configured Authentication providers. This setting is the default.
• REQUISITE—This LoginModule must succeed. If other Authentication providers are configured and this LoginModule succeeds, authentication proceeds down the list of LoginModules. Otherwise, return control to the application.
• SUFFICIENT—This LoginModule needs not succeed. If it does succeed, return control to the application. If it fails and other Authentication providers are configured, authentication proceeds down the LoginModule list.
• OPTIONAL—This LoginModule need not succeed. Whether it succeeds or fails, authentication proceeds down the LoginModule list.

 

---

Configuring an LDAP Authentication Provider

WebLogic Server does not support or certify any particular LDAP servers. Any LDAP v2 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:

• Setting LDAP Server and Caching Information
• Locating Users in the LDAP Directory
• Locating Groups in the LDAP Directory
• Locating Members of a Group in the LDAP Directory

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 (referred to as the Administration Console), assign that group the Admin role.

Configuring a LDAP Authentication Provider

To configure an LDAP Authentication provider:

1. Expand the Security-->Realms nodes.
2. Click 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 for the realm that is being configured.

4. Choose an LDAP Authentication provider.
   • Configure a new Active Directory Authenticator...
   • Configure a new Novell Authenticator...
   • Configure a new iPlanet Authenticator...
   • Configure a new Open LDAP 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. For more information, see [xref].
6. Click Apply to save your changes.
7. Proceed to [xref].

Setting LDAP Server and Caching Information

To set LDAP server and caching information:

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

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.

   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.

   
    

3. To save your changes, click Apply.
4. Proceed to [xref].

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 the SSL Protocol.

Locating Users in the LDAP Directory

To specify how users are located in the LDAP directory:

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

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.

   Table 3-3 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.
   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 [xref].

Locating Groups in the LDAP Directory

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

1. Click the Groups tab under the Configuration tab.

   For example, click the Groups tab under the iPlanet Configuration 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.

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

   
    

3. To save your changes, click Apply.
4. Proceed to [xref].

Locating Members of a Group in the LDAP Directory

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:

1. Click on the Membership tab under the Configuration tab.

   For example, click the Membership tab under the iPlanet Configuration 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.

   Table 3-5 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 supported with the Active Directory, Open LDAP, or Novell NDS directory servers, so set this attribute to NUL 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 supported with the Active Directory, Open LDAP, or Novell NDS directory servers, so set this attribute to NUL 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 supported with the Active Directory, Open LDAP, or Novell NDS directory servers, so set this attribute to NUL 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.

 

---

Configuring a WebLogic Authentication Provider

Note: The 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 Configuring the Embedded LDAP Server.
1. Expand the Security-->Realms nodes.
2. Click 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 for the realm being configured.

4. Choose the Configure a new Default Authenticator... link.
5. 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 [xref].
6. Click Apply to save your changes.
7. Optionally, configure additional Authentication and/or Identity Assertion providers.
8. 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 WebLogic security providers in WebLogic Server version 7.0. Use the Realm Adapter Authentication provider if you store users and groups in the 6.x Windows NT, UNIX, RDBMS or custom security realms. (There are no equivalents to the 6.x Windows NT, UNIX, RDBMS security realms in WebLogic Server 7.0). When using Compatibility Security, a Realm Adapter Authentication provider is by default configured for the Compatibility realm.

The Realm Adapter Authentication provider also allows you to use implementations of the weblogic.security.acl.CertAuthenticator class with WebLogic Server 7.0. 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 7.0, see Using a CertAuthenticator in Compatibility Security in the Upgrade Guide for BEA WebLogic Server 7.0.

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 configure the Realm Adapter Authentication provider to access groups and users from 6.x security realms:

1. Boot WebLogic Server to run Compatibility Security. For more information, see [xref Upgrade].
2. Ensure that the Realm Adapter Authentication provider in the Compatibility realm is populated with users and groups from the 6.x security realm (Windows NT, UNIX, RDBMS or Custom security realms). The users and groups should appear in the Users and Groups table. The user and group information is copied into a filerealm.properties file.
3. Expand the Security-->Realms nodes.
4. Click the name of the realm you are configuring (for example, TestRealm).
5. Expand the Providers-->Authentication Providers nodes.

   The Authenticators table displays the name of the default Authentication and Identity Assertion providers for the realm that is being configured.

6. Choose the Configure a new Realm Adapter Authenticator... link.
7. Define values for the attributes on the General tab.
   • The Control Flag attribute determines how the Realm Adapter Authentication provider is used with other Authentication providers. Set the Control Flag attribute to OPTIONAL.
   • The Supported Types attribute lists the type of tokens supported by the Identity Assertion provider. The Identity Assertion provider in the Realm Adapter Authentication provider supports only X.509 tokens. This token type provides backward compatibility for implementations of the weblogic.security.acl.CertAuthenticator class. This attribute is read-only.
   • The Active Type attribute defines what type of token is currently being used by the Identity Assertion provider. Multiple Identity Assertion providers in a security realm can support the same token type. However, only one Identity Assertion provider in a security realm can have a particular token type active. If two Identity Assertion providers have the same type of token defined in the Active Type attribute, the first Identity Assertion provider configured in the realm handles that type of token. The Identity Assertion provider in the Realm Adapter Authenticator supports X.509 token types.
8. Click Apply to save your changes.
9. Set the Control Flag attribute on the WebLogic Authentication provider to SUFFICIENT.
10. Optionally, configure additional Authentication and/or Identity Assertion providers.
11. Reboot WebLogic Server.

 

---

Configuring a WebLogic Identity Assertion Provider

Note: The Administration Console refers to the WebLogic Identity Assertion provider as the Default Identity Asserter.

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 handle one or more token formats. 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).

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

The WebLogic Identity Assertion provider supports identity assertion using X509 certificates and CORBA Common Secure Interoperability version 2 (CSI v2). When you finish defining attributes for the WebLogic Identity Assertion provider, reboot WebLogic Server.

To define attributes for the WebLogic Identity Assertion provider:

1. Expand the Security-->Realms nodes.
2. Click 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 for the realm that is being configured.

4. Choose the Configure a new Default Identity Asserter... link from the Authenticators tab.
5. Define values for the attributes on the General tab.
   • The User Name Mapper Class Name attribute specifies your implementation of the weblogic.security.providers.authentication.UserNameMapper interface. This interface maps a certificate to a user name according to whatever scheme is appropriate for your needs. You can also use this interface to map from a X.501 distinguished name to a user name.

Note: The implementation of the weblogic.security.providers.authentication.UserNameMapper interface must be specified in your CLASSPATH.

• The Trusted Client Principals attribute defines a list of client principals that can use CSIv2 identity assertion. You can use an asterisk (*) to specify all client principals.

When you use client certificates with the SSL protocol, there is trust associated with a certificate. However, because CSIv2 contains no proof, there is no trust associated with any of the CSIv2 identity assertion tokens. A malicious user could create CSIv2 tokens for any user. This attribute provides a way to limit the set of principals that can assert identity via CSIv2.

6. Click Apply to save your changes.
7. Optionally, configure additional Authentication and/or Identity Assertion providers.
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. For information about configuring a custom security provider (including a Custom Authorization provider), see Configuring a Custom Security Provider

Note: The Administration Console refers to the WebLogic Authorization provider as the Default Authorizer.

To configure a WebLogic Authorization provider:

1. Expand the Security-->Realms nodes.
2. Click 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 from a deployment descriptor) 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.

   For more information, see The Components of an Authorization Provider in Developing Security Services for WebLogic 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.

For more information about credential maps and their use in resource adapters, see Providing WebLogic Server Users Access to Other Applications and the Security topic in Programming the J2EE Connector Architecture.

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:

1. Expand the Security-->Realms nodes.
2. Click the name of the realm you are configuring (for example, TestRealm).
3. Expand the Providers node.
4. Click Credential Mappers.

   The Credential Mappers table displays the name of the default Credential Mapping provider for the realm that is being configured.

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 a 6.x Resource Adapter Archive (RAR). 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.

   For more information, see Implementing the DeployableCredentialMappingProvider SSPI in Developing Security Services for WebLogic Server.

7. Click Apply to save your changes.
8. Reboot WebLogic Server.

 

---

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 Customizing the Default Security Configuration

To configure an Role Mapping provider:

1. Expand the Security node.
2. Expand the Realms node.
3. Click the name of the realm you are configuring (for example, TestRealm).
4. Click the Providers node.
5. 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.

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

   The General tab appears.

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

   For more information, see The Role Mapping Providers in Developing Security Services for WebLogic Server.

8. Click Apply to save your changes.
9. Reboot WebLogic Server.

 

---

Configuring a Custom Security Provider

To configure a Custom security provider:

1. Write a Custom security provider. For more information, see Developing Security Providers for WebLogic Server.
2. Put the MBean JAR file for the provider in the WL_HOME\lib\mbeantypes directory.
3. Start the Administration Console.
4. Expand the Security-->Realms nodes.
5. Click on the name of the realm you are configuring (for example, TestRealm.)
6. Expand the Providers node.
7. 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.

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

9. The General tab appears.

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

10. If desired, adjust the values for the attributes for the Custom Security provider.
11. Click Apply to save your changes.
12. Reboot WebLogic Server.

 

---

Deleting a Security Provider

To delete a security provider:

1. Expand the Security-->Realms nodes.
2. Click the name of the realm in which the provider you want to delete is configured (for example, TestRealm).
3. Expand the Providers node.
4. Click 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 available providers.
6. To delete a provider, click on the trash can icon in the corresponding row of the provider table.
7. Reboot WebLogic Server.

Note: The WebLogic Securiy providers stored their data in the embedded LDAP server. When you delete a WebLogic Security provider, the security data in the embedded LDAP server is not automatically deleted. The security data remains in the embedded LDAP server in case you want to use the provider again. Use an external LDAP browser to delete the security data from the embedded LDAP server.

 

---

Creating a New Security Realm: Main Steps

To configure a new security realm:

1. Expand the Security node.
2. Expand the Realms node.

   All the security realms available for the WebLogic domain are listed in the Realms table.

3. Click the Configure a new Realm... link.
4. Enter the name of the new security realm in the Name attribute on the General tab.
5. Set the Ignore Security Data in Deployment Descriptors attribute as desired. For more information, see [xref].
6. Click Create.
7. Configure the required security providers for the security realm. In order for a security realm to be valid, you must configure an Authentication provider, an Authorization provider, an Adjudication provider, a Credential Mapping provider, and a Role Mapping provider. Otherwise, you will not be able to set the new security realm as the default security realm.
8. Optionally, define an Identity Assertion and Auditing provider.
9. Define groups and users for the security realm. [xref]
10. Grant users and groups in the security realm roles. [xref]
11. Protect WebLogic resources in the security realm with security policies.
12. Reboot WebLogic Server. If you do not reboot WebLogic Server, you cannot set the realm to the default security realm.
13. Set the new realm as the default security realm for the WebLogic domain. [xref]

 

---

Loading Security Data from Deployment Descriptors into the Security Providers

On application deployment, WebLogic Server reads security and credential information from the weblogic.xml, weblogic-ejb-jar.xml, and weblogic-ra.xml files. Once the security and credential information is loaded into the Administration Console, security and credential mapping changes are not persisted to the weblogic.xml, weblogic-ejb-jar.xml, and weblogic-ra.xml files.

Before you redeploy the application (which will happen when you redeploy it through the Administration Console, modify it on disk, or restart WebLogic Server), you need to enable the Ignore Security Data in Deployment Descriptors attribute on the Security-->Realm General tab. Otherwise, the old data in the weblogic.xml, weblogic-ejb-jar.xml, and weblogic-ra.xml files will overwrite any changes made through the Administration Console.

To avoid overwriting Administration Console changes with old information from the weblogic.xml, weblogic-ejb-jar.xml, and weblogic-ra.xml files:

1. Expand the Security-->Realms nodes.
2. Click the name of the realm (for example, TestRealm).
3. In the General tab, enable the Ignore Security Data in Deployment Descriptors attribute.
4. Click Apply to save your changes.
5. Reboot WebLogic Server.

 

---

Changing the Default Security Realm

By default, WebLogic Server sets the myrealm as the default security realm.

To change the default security realm:

1. Configure a new security realm. For more information, see [xref].
2. Reboot WebLogic Server.
3. Expand the Domain node.
4. Select the Security-->General tab.

   The pull-down menu on the Default Realm attribute displays the security realms configured in the WebLogic domain.

   Note: If you create a new security realm but do not configure the required security providers, the realm will not be available from the pull-down menu.

5. Select the security realm you want to set as the default security realm.
6. Click Apply.
7. Reboot WebLogic Server. If you not reboot WebLogic Server, the new realm is not set as the default security realm.

To verify you set the default security realm correctly:

1. Expand the Security-->Realms nodes.

   The General tab shows all realms configured for the WebLogic domain. The default security realm has the Default Realm attribute set to true.

After you set a realm as the default security realm, complete the process of configuring security by performing the tasks in Configuring WebLogic Security.

 

---

Deleting a Security Realm

When you delete a security realm, the user, group, role, security policy, and credential map information is not deleted from the embedded LDAP server.

To delete a security realm:

1. Expand the Security-->Realms nodes.

   The Realm table lists all realms configured for the WebLogic domain.

2. To delete a security realm, click the trash can icon in the corresponding row of the Realm table.
3. Click Yes in response to the following question:

   Are you sure you want to permanently delete OldRealm from the domain configuration?

   A confirmation message appears when the security realm is deleted.