Security Realms

 

 

General

  1. Overview
  2. Users
  3. Groups
  4. Security Roles
  5. Security Policies

Providers

  1. Overview
  2. Embedded LDAP Server
  3. Authentication
  4. Identity Assertion
  5. Principal Validation
  6. Authorization
  7. Adjudication
  8. Role Mapping
  9. Auditing
  10. Credential Mapping
  11. Keystore
  12. Realm Adapter
  13. Security Providers and Security Realms

 

Overview

Security realms protect WebLogic resources using security role and security providers.

 

Users

Entities that can be authenticated in a security realm. A user can be a person or a software entity As a result of authentication, a user is assigned a unique identity, or principal. Users may be placed into groups that are associated with security roles, or be directly associated with security roles.

If WLS can verify the identity of the user based on that username and credential, WLS 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, WLS checks the security policy of the resource.

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

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

 

Groups

Logically ordered sets of user. For example, a company could have sales, engineering, and operations groups.

Groups are assigned security roles, and then the security roles are associated with a resource via a security policy.

User names and groups must be unique within a security realm.

 

Security Roles

Privilege granted to users or groups based on specific conditions, allowing one to restrict access to resources for several users at once. Unlike groups, security roles:

  1. Are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day.

  2. Can be scoped to specific resources within a single application in a WLS domain. Groups are always scoped to an entire 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.

In WLS 6.x, security roles applied to Webapps and Enterprise JavaBeans (EJBs) only. In this release of WLS, the use of security roles is expanded to include all of the defined resources.

 

Security Policies

Association between a resource and one or more users, groups, or security roles. A WebLogic resource has no protection until you create a security policy for it.

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

 

Security Providers

Software modules that provide security services to webapps.

Default providers are bundled with WLS. You can also purchase custom security providers or develop your own custom security providers.

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.

For example:

  1. An Authentication provider requires information about users and groups

  2. An Authorization provider requires information about security policies

  3. A Role Mapping provider requires information about security roles

  4. A Credential Mapping provider requires information about credentials to be used with a Resource Adapter to access an Enterprise Information System.

These security providers need this information to be available in a database in order to function properly.

The security provider database can be:

Sample custom security providers are available at BEA dev2dev Web site.

At minimum, the security provider database is initialized with the default groups, security roles, security policies provided by WLS.

 

Embedded LDAP Server

Stores user, group, security roles, and security policies and serves them to WebLogic security providers.

Usage by the various security providers includes:

Provider 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 resource.
Auditing None.
Credential Mapping Stores Username-Password credential mapping information.

 

Authentication Providers

Use LoginModules to validate users through:

You must have at least one Authentication provider in a security realm.

Authentication providers can also use Principal Validation providers which provide additional security by signing and verifying the authenticity of principals. Because they add security to the principals used in authentication, a Principal Validation provider must be accessible to your Authentication providers.

 

Identity Assertion Providers

Using client-supplied tokens, map a client identity to a username. Authentication providers LoginModule use these mappings to convert usernames to principals. Token types Kerberos, Security Assertion Markup Language, and Microsoft Passport.

The default user name mappers bundled with WLS for X.501 and X.509 certificates are weblogic.security.providers.authentication and DefaultUserNameMapperImpl. You can also develop your own implementation of the weblogic.security.providers.authentication.UserNameMapper interface.

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 (single-sign on)

Only one token type at a time can be active in a particular 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 can be used 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 support perimeter-based authentication (Web server, firewall, VPN).

 

Principal Validation Providers

Used by Authentication providers to provide additional security protections by signing and verifying the authenticity of the principals, providiing an additional level of trust. Verification takes place during the WLS's demarshalling of RMI client requests for each invocation.

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.

WLS configures the required Principal Validation providers for you when you configure your Authentication providers. You cannot use the console to configure Principal Validation providers directly.

 

Authorization Providers

Control access to resources based on the security role a user or group is granted, and the security policy assigned to the requested resource.

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

You must have at least one Authorization provider in a security realm.

You can have multiple Authorization providers to handle different resources and principals. For example, one to handle executive employees and another to handle salaried employees.

 

Adjudication Providers

If multiple Authorization providers are configured, each may return a different answer to the "is access allowed?" question. Answers include 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, which weighs each Access Decision's answer and returns a final result.

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

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. This value can be changed to PERMIT using the console.

 

Role Mapping Providers

Supply Authorization providers with security role information. We want to answer the question, "is access allowed?", for each resource sought.

Security roles are set in deployment descriptors, or through the console.

You must have at least one Role Mapping provider in a security realm.

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.

 

Auditing Providers

Collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation. Different audit severity levels can be set. Audit information can be written to an LDAP back-end, database, or simple file, and specific actions, such as paging security personnel, can be configured.

Authentication and Authorization providers can request audit services before and after security operations using the WebLogic Security Framework.

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

 

Credential Mapping Providers

Map credentials used by WLS to credentials used in a legacy or remote system, allowing WLS to log into a remote system on behalf of a subject that has already been authenticated. There must be at least one Credential Mapping provider in a security realm.

Credential Mapping providers can handle the following types of credentials:

  1. username/password combinations
  2. Kerberos tickets
  3. public key certificates

Credential mappings are set in deployment descriptors or through the consolea>.

 

Keystore Providers

Creates and manages password-protected stores of private keys, public key certificates, and trusted certificate authorities.

The WebLogic Keystore provider that is included as part of the WLS product is used to obtain secured private keys from keystores.

The WebLogic Keystore provider is deprecated in this release of WLS but is still supported. The development of custom Keystore providers is not supported. Rather, use Java KeyStores instead.

 

Realm Adapter Providers

Provides 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 WLS. The Realm Adapter providers map the realm API (weblogic.security.acl) used in WLS 6.x to the APIs used in this release of WLS.

 

Security Providers and Security Realms

All security providers exist within the context of a security realm. The table below summarizes which security providers must be configured for an 8.1 security realm to operate:

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

  Home