Security Realms

This section covers the following topics:

 

Introduction to Security Realms

In this release of WebLogic Server, a security realm comprises mechanisms for protecting WebLogic resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies (see Figure 3-1). A user must be defined in a security realm in order to access any WebLogic resources belonging to that realm. When a user attempts to access a particular WebLogic resource, WebLogic Server tries to authenticate and authorize the user by checking the security role assigned to the user in the relevant security realm and the security policy of the particular WebLogic resource.

Figure 3-1 WebLogic Server Security Realm


 

Users

Users are entities that can be authenticated in a security realm, such as myrealm (see Figure 3-1). A user can be a person, such as application end user, or a software entity, such as a client application, or other instances of WebLogic Server. As a result of authentication, a user is assigned an identity, or principal. Each user is given a unique identity within the security realm. Users may be placed into groups that are associated with security roles, or be directly associated with security roles.

When users want to access WebLogic Server, they present proof material (for example, a password or a digital certificate) typically through a JAAS LoginModule to the Authentication provider configured in the security realm. If WebLogic Server can verify the identity of the user based on that username and credential, WebLogic Server associates the principal assigned to the user with a thread that executes code on behalf of the user. Before the thread begins executing code, however, WebLogic Server checks the security policy of the WebLogic resource and the principal (that the user has been assigned) to make sure that the user has the required permissions to continue.

When you use the WebLogic Authentication provider and you define a user, you also define a password for that user. WebLogic Server hashes all passwords. Subsequently, when WebLogic Server receives a client request, the password presented by the client is hashed and WebLogic Server compares it to the already hashed password to see if it matches.

Note: All user names and groups must be unique within a security realm.

For more information, see Users and Groups" in Securing WebLogic Resources

 

Groups

Groups are logically ordered sets of users (see Figure 3-1). Usually, group members have something in common. For example, a company may separate its sales staff into two groups, Sales Representatives and Sales Managers. Companies may do this because they want their sales personnel to have different levels of access to WebLogic resources, depending on their job functions.

Managing groups is more efficient than managing large numbers of users individually. For example, an administrator can specify permissions for 50 users at one time by placing the users in a group, assigning the group to a security role, and then associating the security role with a WebLogic resource via a security policy.

All user names and groups must be unique within a security realm.

For more information, see Users and Groups" in Securing WebLogic Resources

 

Security Roles

A security role is a privilege granted to users or groups based on specific conditions (see Figure 3-1). Like groups, security roles allow you to restrict access to WebLogic resources for several users at once. However, unlike groups, security roles:

  • Are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day.
  • Can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain (unlike groups, which are always scoped to an entire WebLogic Server domain).

Granting a security role to a user or a group confers the defined access privileges to that user or group, as long as the user or group is "in" the security role. Multiple users or groups can be granted a single security role.

Note: In WebLogic Server 6.x, security roles applied to Web applications and Enterprise JavaBeans only. In this release of WebLogic Server, the use of security roles is expanded to include all of the defined WebLogic resources.

For more information on security roles, see Security Roles in Securing WebLogic Resources.

 

Security Policies

A security policy is an association between a WebLogic resource and one or more users, groups, or security roles. Security policies protect the WebLogic resource against unauthorized access. A WebLogic resource has no protection until you create a security policy for it.

Note: Security policies replace the access control lists (ACLs) that were used to protect WebLogic resources in WebLogic Server 6.x.

For more information on security policies, see Security Policies.

 

Security Providers

Security providers are modules that provide security services to applications to protect WebLogic resources (see Figure 3-1). You can use the security providers that are provided as part of the WebLogic Server product, purchase custom security providers from third-party security vendors, or develop your own custom security providers. For information on how to develop custom security providers, see Developing Security Providers for WebLogic Server.

The following topics are discussed in this section.

 

Security Provider Databases

The following sections explain what a security provider database is and describe how security realms affect the use of security provider databases:

 

What Is a Security Provider Database?

A security provider database contains the users, groups, security roles, security policies, and credentials used by some types of security providers to provide security services (see Figure 3-1). For example: an Authentication provider requires information about users and groups; an Authorization provider requires information about security policies; a Role Mapping provider requires information about security roles, and a Credential Mapping provider requires information about credentials to be used with a Resource Adapter to access an Enterprise Information System (EIS). These security providers need this information to be available in a database in order to function properly.

The security provider database can be the embedded LDAP server (as used by the WebLogic security providers), a properties file (as used by the sample custom security providers, available on the Web), or a production-quality, customer-supplied database that you may already be using. Note that the sample custom security providers are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site.

The security provider database should be initialized the first time security providers are used. (That is, before the security realm containing the security providers is set as the default (active) security realm.) This initialization can be done:

  • When a WebLogic Server instance boots.
  • When a call is made to one of the security provider's MBeans.

At minimum, the security provider database is initialized with the default groups, security roles, security policies provided by WebLogic Server. For more information, see Security Providers and WebLogic Resources in Developing Security Providers for WebLogic Server.

 

Security Realms and Security Provider Databases

If you have multiple security providers of the same type configured in the same security realm, these security providers may use the same security provider database. This behavior holds true for all of the WebLogic security providers and the sample security providers that are available http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site.

For example, if you configure two WebLogic Authentication providers in the default security realm (called myrealm), both WebLogic Authentication providers will use the same location in the embedded LDAP server as their security provider database, and thus, will use the same users and groups. Furthermore, if you or an administrator add a user or group to one of the WebLogic Authentication providers, you will see that user or group appear for the other WebLogic Authentication provider as well.

Note: If you have two WebLogic security providers (or two sample security providers) of the same type configured in two different security realms, each will use its own security provider database. Only one security realm can be active at a time.

Custom security providers that you develop (or the custom security providers that you obtain from third-party security vendors) can be designed so that each instance of the security provider uses its own database or so that all instances of the security provider in a security realm share the same database. This is a design decision that you need to make based on your existing systems and security requirements. For more information about design decisions that affect security providers, see Design Considerations in Developing Security Providers for WebLogic Server.

 

Embedded LDAP Server

The embedded LDAP server is used as the database that stores user, group, security roles, and security policies for the WebLogic security providers. The embedded LDAP server is a complete LDAP server. It supports the following access and storage functions:

  • Access and modification of entries in the LDAP server
  • Use of an LDAP browser to import and export security data into and from the LDAP server.
  • Read and write access by the WebLogic security providers.

    Note: WebLogic Server does not support adding attributes to the embedded LDAP server.

Table 3-1 shows how each of the WebLogic security providers uses the embedded LDAP server.

WebLogic Security Provider

Embedded LDAP Server Usage

Authentication Stores user and group information.
Identity Assertion Stores user and group information.
Authorization Stores security roles and security policies.
Adjudication None.
Role Mapping Supports dynamic role associations by obtaining a computed set of roles granted to a requestor for a given WebLogic resource.
Auditing None.
Credential Mapping Stores Username-Password credential mapping information.

 

Types of Security Providers

The following sections describe the types of security providers that you can use with WebLogic Server:

Note: You cannot develop a single security provider that merges several provider types (for example, you cannot have one security provider that does authorization and role mapping).

 

Authentication Providers

Authentication providers allow WebLogic Server to establish trust by validating a user. The WebLogic Server security architecture supports Authentication providers that perform: username/password authentication, certificate-based authentication directly with WebLogic Server, and HTTP certificate-based authentication proxied through an external Web server.

Note: An Identity Assertion provider is a special type of Authentication provider that handles perimeter-based authentication and multiple security token types/protocols. For more information, see Identity Assertion Providers.

A LoginModule is the part of an Authentication provider that actually performs the authentication of a user or system. Authentication providers also use Principal Validation providers which provide additional security by signing and verifying the authenticity of principals (users/groups). For more information about Principal Validation providers, see Principal Validation Providers in Developing Security Providers for WebLogic Server.

You must have at least one Authentication provider in a security realm, and you can configure multiple Authentication providers in a security realm. Having multiple Authentication providers allows you to have multiple LoginModules, each of which may perform a different kind of authentication. An administrator configures each Authentication provider to determine how multiple LoginModules are called when users attempt to login to the system. Because they add security to the principals used in authentication, a Principal Validation provider must be accessible to your Authentication providers.

Authentication providers and LoginModules are discussed in more detail in Authentication Providers in Developing Security Providers for WebLogic Server.

 

Identity Assertion Providers

Identity assertion involves establishing a client's identity using client-supplied tokens that may exist outside of the request. Thus, the function of an Identity Assertion provider is to validate and map a token to a username. Once this mapping is complete, an Authentication provider's LoginModule can be used to convert the username to principals. Identity Assertion providers allow WebLogic Server to establish trust by validating a user.

An Identity Assertion provider is a specific form of Authentication provider that allows users or system processes to assert their identity using tokens (in other words, perimeter authentication). You can use an Identity Assertion provider in place of an Authentication provider if you create a LoginModule for the Identity Assertion provider, or in addition to an Authentication provider if you want to use the Authentication provider's LoginModule. Identity Assertion providers enable perimeter authentication and support single sign-on.

The WebLogic Server security architecture supports Identity Assertion providers that perform perimeter-based authentication (Web server, firewall, VPN). You can write Identity Assertion providers that support different token types, such as Kerberos, SAML (Security Assertion Markup Language) and Microsoft Passport, and can handle multiple security protocols (SOAP, IIOP-CSIv2). When used with an Authentication provider's LoginModule, Identity Assertion providers support single sign-on. For example, the Identity Assertion provider can generate a token from a digital certificate, and that token can be passed around the system so that users are not asked to sign on more than once.

Note: To use the WebLogic Identity Assertion provider for X.501 and X.509 certificates, you have the option of using the default user name mapper that is supplied with the WebLogic Server product (weblogic.security.providers.authentication. DefaultUserNameMapperImpl) or providing you own implementation of the weblogic.security.providers.authentication.UserNameMapper interface. For more information, see Do I Need to Develop a Custom Identity Assertion Provider? in Developing Security Providers for WebLogic Server.

Multiple Identity Assertion providers can be configured in a security realm, but none are required. An Identity Assertion provider can support more than one token type, but only one token type at a time can be active in a particular Identity Assertion provider. For example, a particular Identity Assertion provider can support both Kerberos and SAML, but an administrator configuring the system must select which token type (Kerberos or SAML) is to be active in that Identity Assertion provider. For example, if there only one Identity Assertion provider configured and it is set to handle Kerberos tokens, but SAML token types must be supported as well, then another Identity Assertion provider must be configured that can handle SAML tokens and SAML must be set as its active token type.

Identity Assertion providers are discussed in more detail in Identity Assertion Providers in Developing Security Providers for WebLogic Server.

 

Principal Validation Providers

A Principal Validation provider is a special type of security provider that primarily acts as a "helper" to an Authentication provider. Because some LoginModules can be remotely executed on behalf of RMI clients, and because the client application code can retain the authenticated subject between programmatic server invocations, Authentication providers rely on Principal Validation providers to provide additional security protections for the principals contained within the subject.

Principal Validation providers provide these additional security protections by signing and verifying the authenticity of the principals. This principal validation provides an additional level of trust and may reduce the likelihood of malicious principal tampering. Verification of the subject's principals takes place during the WebLogic Server's demarshalling of RMI client requests for each invocation. The authenticity of the subject's principals is also verified when making authorization decisions.

Because have at least one Authentication provider in a security realm, also have one Principal Validation provider in a security realm. If you have multiple Authentication providers, each of those Authentication providers must have a corresponding Principal Validation provider.

Note: You cannot use the Administration Console to configure Principal Validation providers directly. WebLogic Server configures the required Principal Validation providers for you when you configure your Authentication providers.

Principal Validation providers are discussed in more detail in Principal Validation Providers in Developing Security Providers for WebLogic Server.

 

Authorization Providers

Authorization providers control access to WebLogic resources based on the security role a user or group is granted, and the security policy assigned to the requested WebLogic resource. For more information about WebLogic resources, security roles, and security policies, see Securing WebLogic Resources."

An Access Decision is the part of the Authorization provider that actually determines whether a subject has permission to perform a given operation on a WebLogic resource. For more information about, see Principal Validation Providers in Developing Security Providers for WebLogic Server.

You must have at least one Authorization provider in a security realm, and you can configure multiple Authorization providers in a security realm. Having multiple Authorization providers allows you to follow a more modular design. For example, you may want to have one Authorization provider that handles Web application and Enterprise JavaBean (EJB) permissions and another that handles permissions for other types of WebLogic resources. Another example might be to have one Authorization provider that handles domestic employees, and another that handles permissions for overseas employees.

Authorization providers and Access Decisions are discussed in more detail in Authorization Providers in Developing Security Providers for WebLogic Server.

 

Adjudication Providers

As part of an Authorization provider, an Access Decision determines whether a subject has permission to access a given WebLogic resource. Therefore, if multiple Authorization providers are configured, each may return a different answer to the "is access allowed?" question. These answers may be PERMIT, DENY, or ABSTAIN. Determining what to do if multiple Authorization providers' Access Decisions do not agree on an answer is the function of an Adjudication provider. The Adjudication provider resolves authorization conflicts by weighing each Access Decision's answer and returning a final result. If you only have one Authorization provider and no Adjudication provider, then an ABSTAIN returned from the single Authorization provider's Access Decision is treated like a DENY. Note that the WebLogic Adjudication provider supports the use of the Administration Console to control whether an abstain is treated as a permit or a deny.

You must configure an Adjudication provider in a security realm only if you have multiple Authorization providers configured. You can have only one Adjudication provider in a security realm.

Note: Since the default security realm has only one Authorization provider, it does not require an Adjudication provider, even though an Adjudication provider is provided. However, the Compatibility realm has two Authorization providers, so that realm does require an Adjudication provider.

Adjudication providers are discussed in more detail in Adjudication Providers in Developing Security Providers for WebLogic Server.

 

Role Mapping Providers

A Role Mapping provider supports dynamic role associations by obtaining a computed set of security roles granted to a requestor for a given WebLogic resource. The WebLogic Security Framework determines which security roles (if any) apply to a particular subject at the moment that access is required for a given WebLogic resource by:

  • Obtaining security roles from the J2EE and WebLogic deployment descriptor files.
  • Using business logic and the current operation parameters to determine security roles.

A Role Mapping provider supplies Authorization providers with this security role information so that the Authorization provider can answer the "is access allowed?" question for WebLogic resources that use role-based security (that is, Web application and Enterprise JavaBean container resources).

You set security roles in J2EE deployment descriptors, or create them using the WebLogic Server Administration Console. Security roles set in deployment descriptors are applied at deployment time (unless you specifically choose to ignore deployment descriptors).

You must have at least one Role Mapping provider in a security realm, and you can configure multiple Role Mapping providers in a security realm. Having multiple Role Mapping providers allows you to work within existing infrastructure requirements (for example, configuring one Role Mapping provider for each LDAP server that contains user and security role information), or follow a more modular design (for example, configuring one Role Mapping provider that handles mappings for Web applications and Enterprise JavaBeans and another that handles mappings for other types of WebLogic resources).

Note: If multiple Role Mapping providers are configured, the set of security roles returned by all Role Mapping providers will be intersected by the WebLogic Security Framework. That is, security role names from all the Role Mapping providers will be merged into single list, with duplicates removed.

Role Mapping providers are discussed in more detail in Role Mapping Providers in Developing Security Providers for WebLogic Server.

 

Auditing Providers

An Auditing provider collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation. An Auditing provider makes the decision about whether to audit a particular event based on specific audit criteria, including audit severity levels. Auditing providers can write the audit information to output repositories such as an LDAP back-end, database, or simple file. Specific actions, such as paging security personnel, can also be configured as part of an Auditing provider.

Other types of security providers (such as Authentication or Authorization providers) can request audit services before and after security operations have been performed by calling through the WebLogic Security Framework. For more information, see Auditing Events From Custom Security Providers in Developing Security Providers for WebLogic Server.

You can configure multiple Auditing providers in a security realm, but none are required.

Auditing providers are discussed in more detail in Auditing Providers in Developing Security Providers for WebLogic Server.

 

Credential Mapping Providers

A credential map is a mapping of credentials used by WebLogic Server to credentials used in a legacy (or any remote) system, which tell WebLogic Server how to connect to a given resource in that system. In other words, credential maps allow WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated.

A Credential Mapping provider can handle several different types of credentials (for example, username/password combinations, Kerberos tickets, and public key certificates). You can set credential mappings in deployment descriptors or by using the WebLogic Server Administration Console. These credential mappings are applied at deploy time (unless you specifically choose to ignore the credential mappings).

You must have at least one Credential Mapping provider in a security realm, and you can configure multiple Credential Mapping providers in a security realm. If multiple Credential Mapping providers are configured, then the WebLogic Security Framework calls into each Credential Mapping provider to find out if they contain the type of credentials requested by the container. The WebLogic Security Framework then accumulates and returns all the credentials as a list.

Credential Mapping providers are discussed in more detail in Credential Mapping Providers in Developing Security Providers for WebLogic Server.

 

Keystore Providers

With WebLogic Server, a keystore creates and manages password-protected stores of private keys (and their associated public key certificates) and trusted certificate authorities.

The WebLogic Keystore provider that is included as part of the WebLogic Server product is used to obtain secured private keys from keystores. Note that the WebLogic Keystore provider is deprecated in this release of WebLogic Server but is still supported. The development of custom Keystore providers is not supported. Use Java KeyStores (JKS) instead. All of the functionality that was supported by the WebLogic Keystore provider is available through use of Java KeyStores. The WebLogic Keystore provider is only supported for backward compatibility. BEA recommends using the WebLogic Keystore provider only when it is needed to support backward compatibility with a WebLogic Server 7.0 configuration. For information on how to use Java KeyStores, see Configuring Keystores in Managing WebLogic Server.

 

Realm Adapter Providers

Realm Adapter providers provide backward-compatibility with 6.x WebLogic security realms by allowing the use of existing, 6.x security realms with the security features in this release of WebLogic Server. The Realm Adapter providers map the realm API (weblogic.security.acl) used in WebLogic Server 6.x to the APIs used in this release of WebLogic Server. Figure 3-2 shows a Compatibility realm and the types of security providers supported.

Figure 3-2 Compatibility Realm


 

Security Provider Summary

Table 3-2 indicates whether you can configure multiple security providers of the same type in a security realm.

Type

Multiple Providers Supported?

Authentication provider Yes
Identity Assertion provider Yes
Principal Validation provider Yes
Authorization provider Yes
Adjudication provider No
Role Mapping provider Yes
Auditing provider Yes
Credential Mapping provider Yes
Keystore provider Yes
Realm Adapter provider Yes for all types of Realm Adapter providers supported except the Adjudication provider. See Figure 3-2 for the supported types.

 

Security Providers and Security Realms

All security providers exist within the context of a security realm. If you are not running a prior, 6.x release of WebLogic Server, the WebLogic Server security realm defined out-of-the-box as the default realm (that is, the active security realm called myrealm) contains the WebLogic security providers displayed in Figure 3-3.

Note: If you are upgrading from a 6.x release to the 8.1 release, your out-of-the-box experience begins with a Compatibility realm - which is initially defined as the default realm - to allow you to work with your existing configuration. Because the 6.x model is deprecated, you need to upgrade your security realm to the 8.1 model. see Security" under "Upgrading WebLogic Server 6.x to Version 8.1" in the Upgrade Guide for BEA WebLogic Server 8.1.

Figure 3-3 WebLogic Security Providers in a Security Realm


Because security providers are individual modules or components that are "plugged into" a WebLogic Server security realm, you can add, replace, or remove a security provider with minimal effort. You can use the WebLogic security providers, custom security providers you develop, security providers obtained from third-party security vendors, or a combination of all three to create a fully-functioning security realm. However, as Figure 3-3 also shows, some types of security providers are required for a 8.1 security realm to operate properly. Table 3-3 summarizes which security providers must be configured for a fully-operational 8.1 security realm.

Type

Required?

Authentication provider Yes
Identity Assertion provider Yes, if using perimeter authentication.
Principal Validation provider Yes
Authorization provider Yes
Adjudication provider Yes, if there are multiple Authorization providers configured.
Role Mapping provider Yes
Auditing provider No
Credential Mapping provider Yes
Keystore provider No Note that the WebLogic Keystore provider is deprecated in this release of WebLogic Server but is still supported. The development of custom Keystore providers is not supported. Use Java KeyStores (JKS) instead. BEA recommends using the WebLogic Keystore provider only when it is needed to support backward compatibility with a WebLogic Server 7.0 configuration. For information on how to use Java KeyStores, see Configuring Keystores in Managing WebLogic Server.

For more information about security realms, see the following topics in Managing WebLogic Security:

Skip navigation bar  Back to Top Previous Next