bea.com | products | dev2dev | support | askBEA |
|
e-docs > WebLogic Server > Managing WebLogic Security > Customizing the Default Security Configuration |
Managing WebLogic Security |
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:
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):
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 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:
The Require Unanimous Permit attribute determines how the WebLogic Adjudication provider handles a combination of PERMIT and ABSTAIN votes from the configured Authorization providers.
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:
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:
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:
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:
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:
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:
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:
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.
Configuring a LDAP Authentication Provider
To configure an LDAP Authentication provider:
Setting LDAP Server and Caching Information
To set LDAP server and caching information:
The following table describes the attributes you set on the LDAP tab.
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:
The following table describes the attributes you set on the Users tab.
Locating Groups in the LDAP Directory
To specify how groups are stored and located in the LDAP directory:
The following table describes the attributes you set on the Groups tab.
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:
The following table describes the attributes you set on the Membership tab.
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:
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:
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:
Note: The implementation of the weblogic.security.providers.authentication.UserNameMapper interface must be specified in your CLASSPATH.
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.
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:
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.
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:
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.
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:
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.
Configuring a Custom Security Provider
To configure a Custom security provider:
To delete a security provider:
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:
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:
Changing the Default Security Realm
By default, WebLogic Server sets the myrealm as the default security realm.
To change the default security realm:
To verify you set the default security realm correctly:
After you set a realm as the default security realm, complete the process of configuring security by performing the tasks in Configuring WebLogic Security.
When you delete a security realm, the user, group, role, security policy, and credential map information is not deleted from the embedded LDAP server.