Skip navigation.
Downloads | Product Documentation | Support

Introduction to WebLogic Enterprise Security

# Security Services

The following sections describe the fundamentals of the BEA WebLogic Enterprise Security services:

- Authentication and Identity
- Role Mapping
- Authorization
- Auditing
- Credential Mapping
- Security Service Providers

# Authentication and Identity

Authentication is the process of verifying an identity claimed by or for a user or system process. An authentication process consists of two steps:

1. Identification—presenting an identifier to the security system.
2. Verification—presenting or generating authentication information that corroborates the binding between the entity and the identifier.

Authentication answers the question, Who are you? using credentials such as username and password combinations. An Authentication provider is used to prove the identity of users or system processes. The Authentication provider also stores, transports, and makes identity information available to various components of a system when needed. During the authentication process, a Principal Validation provider supports additional security protections for the principals (users and groups) contained within the subject, by first signing and later verifying the authenticity of those principals for each use.

## Authentication Service

The Authentication providers support numerous methods of authentication services, including user username/password and identity assertion. In addition, a set of Authentication providers is supplied that access various types of user directories and identity tokens.

Figure 3-1 shows how the authentication process works for a web application that requires a username and password to perform the login. When a user attempts to log into a system using a username and password combination, the Authentication provider establishes trust by validating that username and password. This process also requires the use of a Login Module and a Principal Validation provider, as described in Identity Assertion.

Note: Because the authentication service is implemented using the JAAS standard, developers of custom Authentication providers are involved with the JAAS process directly.

The authentication process requires a valid list of users and groups, through which their identity can be verified. BEA WebLogic Enterprise Security supports any number of LDAP servers or a database.

Figure 3-1 Authentication Service Example for Username and Password

## Types of Authentication

Users must be authenticated whenever a request is made to access a protected resource. For this reason, each user is required to provide a credential (for example, a password). The following types of authentication are supported by the Authentication providers:

- Username and Password Authentication
- Web Single Sign-On
- Perimeter Authentication

You can use one of the Authentication providers provided as part of BEA WebLogic Enterprise Security or you can create a custom authentication provider to perform a different type of authentication. Support for the following methods of user and password authentication include:

- Microsoft Windows NT
- OpenLDAP
- Novell
- Active Directory
- Database

### Username and Password Authentication

In username and password authentication, a user ID and password are requested from the user and sent to the Security Framework. The Security Framework checks the information and, if it is trustworthy, grants access to the protected resource.

You can use Secure Sockets Layer (SSL) or Hyper-Text Transfer Protocol (HTTPS) to provide an additional level of security to username and password authentication. Because SSL encrypts the data transferred between the client and the Security Framework, the username and password are encrypted and not transferred in clear text. Therefore, BEA WebLogic Enterprise Security services can authenticate the user without compromising the confidentiality of the username and password.

### Web Single Sign-On

Web single sign-on is an access-control mechanism that enables users to log on to one web server and gain access to other web servers in the same domain or other domains without supplying log-in credentials again, even though the other web servers may have their own authentication schemes or requirements. Figure 3-2 shows the basic components of a web single sign-on service.

Figure 3-2 Web Single Sign-on

While web single sign-on removes the requirement for users to log on every time they access a different web server and thus makes user access easier, it does not improve security. In fact, you should take security requirements into consideration when implementing a web single sign-on solution.

### Perimeter Authentication

Perimeter authentication is the process of authenticating the identity of a remote user outside of the application server domain. You can use an Identity Assertion provider to establish perimeter authentication—a special type of authentication that uses tokens. The Security Framework supports identity assertion providers that perform perimeter-based authentication and handle multiple security token types and protocols.

#### How is Perimeter Authentication Accomplished?

BEA WebLogic Enterprise Security services are designed to extend the single sign-on concept all the way to the perimeter by using identity assertion (see Figure 3-3). Provided as a critical piece of the Security Framework, the concept of identity assertion allows you to use the authentication mechanism provided by perimeter authentication schemes such as the Checkpoint OPSEC, the emerging Security Assertion Markup Language (SAML), Simple and Protected Negotiation Mechanism (SPNEGO), or enhancements to protocols such as Common Secure Interoperability (IIOP-CSIv2) to achieve this functionality.

Perimeter authentication is typically accomplished by the remote user specifying an asserted identity and some form of corresponding proof material, normally in the form of a passphrase, which is used to perform the verification. The authentication agent, the entity that actually vouches for the identity, can take many forms, including: Web Server, VPN, firewall, enterprise authentication service, or some other form of global identity service. Each of these forms of authentication has one common characteristic-they all perform an authentication process that results in an artifact or token presented to vouch for the authenticated user at a later time.

Currently, the format of the token varies from vendor to vendor, but there are efforts underway to define a standard token format. SAML is an emerging XML-based protocol for exchanging information securely. In addition, there is a current standard for identity attribute certificates that is based on the X.509 standard for digital certificates. But, if the applications and the infrastructure on which they are built are not designed to support this concept, enterprises are still forced to require remote users re-authenticate to the applications within the network. You can develop custom authentication providers that support different token types, including SAML.

Figure 3-3 Perimeter Authentication

Support for perimeter authentication requires the use of one or more identity assertion providers designed to support one or more token formats. You can implement multiple and different identity assertion providers. The tokens are transmitted as part of any normal business request, using the mechanism provided by each protocol supported. Once a request is received, the entity that handles the processing of the protocol message recognizes the existence of the token in the message. This information is used in a call to the Security Framework, which then calls the appropriate identity assertion provider to handle the verification of the token. It is the responsibility of the identity assertion provider implementation to perform whatever actions are necessary to establish validity and trust in the token and to provide the identity of the user with a reasonable degree of assurance, without the need for the user to re-authenticate to the application.

The passphrase entered by the user is a string of characters (typically, much longer than a password) used to create a digitally-encrypted signature (or private or secret key). The passphrase adds an extra level of authentication security to ensure that you are who you say you are.

The following sections describe additional authentication concepts and functionality.

- Principal Validation
- Identity Assertion

## Principal Validation

Subjects and principals are closely related. A principal is an identity assigned to a user or group as a result of authentication. Both users and groups can be used as principals by application servers. The Java Authentication and Authorization Service (JAAS standard) requires that subjects be used as containers for authentication information, including principals. Figure 3-4 illustrates the relationships between users, groups, principals, and subjects.

Figure 3-4 Relationships Between Users, Groups, Principals and Subjects

### Principal Validation Service

Much as an Identity Assertion provider supports a specific type of token, a Principal Validation provider both signs and verifies the authenticity of a principal that represents a user or group. This provides an additional layer of protection for the user identity within the service module.

Note: You do not use the Administration Console to configure Principal Validation providers directly. BEA WebLogic Enterprise Security provides the required Principal Validation providers for you when you configure your Authentication provider.

As shown in Figure 3-5, a user attempts to log into a system using a username and password combination. After the authenticity of the user is verified, the principal validation service signs the principal. The principal validation process then passes the response to the specified Principal Validation provider, which signs the principals and then returns them to the client application. Whenever the principals stored within the subject are required for other security operations, the same Principal Validation provider verifies that the principals stored within the subject were not modified since they were signed.

Figure 3-5 Principal Validation Service

## Identity Assertion

Identity Assertion providers support the mapping of a valid token to a user. You use an Identity Assertion provider to support the specific types of tokens that you use to assert the identities of users or system processes. You can develop an Identity Assertion provider to support multiple token types, but the administrator must configure the Identity Assertion provider so that it validates only one active token type. While you can have multiple Identity Assertion providers in a policy domain with the ability to validate the same token type, only one Identity Assertion provider can actually perform this validation.

The security architecture supports Identity Assertion providers that perform perimeter-based authentication to Web Servers, firewalls, and VPNs. Identity Assertion providers support different token types, such as X.509 certificates (Kerberos), SAML and handles multiple security protocols (such as SOAP and IIOP-CSIv2). When used with an Authentication provider Login Module, 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. The Identity Assertion providers in BEA WebLogic Enterprise Security support the following token types:

- `Authenticated User` type
- CSIv2 principal name identity
- CSIv2 anonymous identity
- CSIv2 X.509 certificate chain identity
- CSIv2 distinguished name identity
- X.509 client certificate
- SAML
- Single Pass Negotiate Identity Asserter (SPNEGO)

### Identity Assertion Service

When perimeter authentication is used (see Figure 3-6), a token from outside of the policy domain is passed to an Identity Assertion provider responsible for validating the type of token configured as active. If the token is successfully validated, the Identity Assertion provider maps the token to a username, sends that username back, and the authentication process continues. Specifically, the username is sent through a JAAS Callback Handler and is passed to each configured Authentication provider Login Module, so that the Login Module can populate the subject with the appropriate principals. Perimeter-based authentication requires the same components as the authentication process, but includes an Identity Assertion provider.

Identity Assertion providers are used as part of perimeter-based authentication process to validate the token type, and then map it to a username. It also specifies a list of trusted client principals to use for identity assertion. The wildcard character (*) can be used to verify that all principals are trusted. If a client is not listed as a trusted client principal, the identity assertion fails and the login is rejected. You can use an Identity Assertion provider in place of an Authentication provider if you create a Login Module for the Identity Assertion provider, or you can use an Identity Assertion provider in addition to an Authentication provider if you want to use the Authentication provider Login Module.

You can configure multiple Identity Assertion providers to support different types of tokens within the same policy domain, but you do not need one unless you are supporting perimeter authentication. Two Identity Assertion providers are supplied: one supports X.509 and IIOP- CSIv2 and one supports SAML. A third Identity Assertion provider supports identity assertion using HTTP authentication tokens from the SPNEGO protocol, to enable single sign-on Cross-Platform authentication capabilities.

When used with a Login Module, Identity Assertion providers support external authentication of a user based on industry standard methods, for example, perimeter authentication or single sign-on. An Identity Assertion provider can generate a local subject. The Login Module that an Identity Assertion provider uses can be part of:

- A custom Authentication provider you develop
- The Authentication provider that BEA provides
- An Authentication provider developed by a third-party security vendor

Unlike a simple authentication situation, the Login Modules that Identity Assertion providers use do not verify proof material such as usernames and passwords; they simply verify that the user exists. The token provides the proof that the user is trusted.

Figure 3-6 Identity Assertion Example

# Role Mapping

Role mapping is the process by which the security service compares users or groups against a security role condition to determine whether a security role is granted. Role mapping occurs dynamically at runtime, just before an Access Decision is rendered for a protected resource.

## Role Mapping Service

The Role Mapping provider determines dynamic roles for a specific user with respect to a specific protected resource. The Security Framework calls each Role Mapping provider that is configured as part of an authorization decision. It can also be used to determine the dynamic roles for the specific user to support personalization (for example, with BEA WebLogic Portal 8.1). Figure 3-7 shows how the Role Mapping provider interacts with the Security Framework to create dynamic role associations.

Figure 3-7 Role Mapping Service

The role mapping process is initiated when a user or system process requests a resource on which it attempts to perform an operation. The resource container that handles the type of resource requested receives the request (for example, the EJB container receives the request for an EJB resource). The resource container calls the Security Framework, and then passes in the request parameters, including information such as the subject (users and groups) of the request, the resource, and the action. The Security Framework calls each configured Role Mapping provider to obtain a list of the roles that apply. If a security policy specifies that the requestor is entitled to a particular role, then the role is added to the list of roles that are applicable to the subject. This process continues until all security policies that apply to the resource or the resource container are evaluated. The list of roles is returned to the framework, where it can be used as part of other operations, such as access decisions.

The result of the dynamic role association performed by the Role Mapping provider is a set of roles that apply to the principals stored in a subject at the time of the request. These roles can then be used to make authorization decisions for protected resources, as well as a resource container and application code. For example, an EJB could use the Java 2 Enterprise Edition (J2EE) method to retrieve fields from a record in a database, without having knowledge of the business policies that determine whether access is allowed.

# Authorization

Authorization is the process whereby the interactions between users and resources are controlled, based on user identity or other information. In other words, authorization answers the question, Can this user access this resource under these conditions? An Authorization provider is used to limit the interactions between users and resources to ensure integrity, confidentiality, and availability. You can optionally define a time constraint for an authorization policy to indicate, When can the user access the resource?

## Authorization Service

The Authorization service determines whether or not a user can access a resource based on the security role and the security policy assigned to the requested resource. Figure 3-8 illustrates how an Authorization provider, and the associated Adjudication and Role Mapping providers, interact with the Security Framework during the authorization process.

Figure 3-8 Authorization Service Example

The authorization process is initiated when a user request is made to perform an operation on a resource. The resource receives the request, calls the Security Framework, and then passes the request parameters to the security providers, including information such as the subject (users and/or groups) of the request, the resource requested, and the action. The Security Framework calls the configured Role Mapping provider using the request parameters to dynamically compute a list of roles to which the user making the request is entitled, and then passes the list of applicable roles back to the Security Framework.

The Authorization provider determines whether the user is entitled to perform the requested action on the resource, based on the user's profile and the supplied resource and role data-that is, the Authorization provider makes an access decision.

The following sections describe authorization concepts and functionality:

- User Directories
- Resources
- Authorization Policies and Role Mapping
- ContextHandlers
- Adjudication

## User Directories

BEA WebLogic Enterprise Security products can access user directories from a variety of sources, including: application databases, Lightweight Directory Access Protocol (LDAP) directory servers, network databases, and others. The type of information or attributes collected—a method typically referred to as profiling—also varies and typically includes: name and address, phone, e-mail address, personal preferences, and more. The information contained in these directories is the core of any authentication service and is key to providing an effective identity management solution.

Users and group information, along with their attributes, are cached in an Oracle or Sybase database table. User data is then available for access to create or enforce authorization policies.

BEA WebLogic Enterprise Security has no control over your user community; your method of storage is completely under your control. For administrative purposes, however, all users must be a member of at least one group.

Figure 3-9 User Attribute Aggregation through Metadirectories

## Resources

A resource is a structured object used to represent an underlying entity that can be protected from unauthorized access using security roles and policies. Resources are hierarchical by nature. Therefore, the level at which you define these roles and policies is up to you. For example, you can define roles and policies on entire EAR, an EJB JAR containing multiple EJBs, a particular EJB within that JAR, or a single method within that EJB. Some typical resources you might want to protect include.

- An application, an application window, or a dialog box
- Specific business transactions, such as a money transfer or security trade
- Application controls, such as buttons and menu selections
- Database or directory server structures
- Web pages, servlets, and EJBs
- Products or services in a portal

## Authorization Policies and Role Mapping

A resource has no protection until it is protected by a policy. In early security systems, an access control list (ACL) was used to protect resources. BEA WebLogic Enterprise Security authorization policies replace ACLs through the use of role-based access control. Like Login Modules for Authentication providers, an access decision is the component of an Authorization provider that actually answers the question, Is access allowed? Specifically, an access decision is asked whether a subject has permission to perform a given operation on a resource, with specific parameters in an application. Given this information, the access decision responds with a result of `PERMIT`, `DENY`, or `ABSTAIN`.

You create an authorization policy by establishing the rules and the permissions for access, based on the resource you want to protect and the role of the requestor; authorization policy focuses on the business process or role, rather than on a user or group. By using role-based access control (RBAC), you separate the process of identifying the requestor (defined through a separate authentication process), from the process of authorization (defined by an access decision). The performance improvement gained by this separation is really quite significant. Once the user is authenticated, the access decision can be made more quickly because there is no need to re-authenticate. The importance and benefit of basing access decisions on roles becomes quite apparent as you can assign large groups of users, who's business functions are the same, to the same role. Because role changes less frequently than user or group status, this mechanism is easily scalable.

You assign policies to any of your resources (for example, a URL, an EJB resource or a JNDI resource) or to attributes or operations of a particular instance of a resource (for example, an EJB method or a servlet within a web application). If you assign a policy to a type of resource, all new instances of that resource inherit that policy.

To use a user or group to create a security policy, the user or group must be defined for the Authentication provider that is configured for the service module to which the provider is associated. For efficiency, this is typically done through the use of roles rather than user or groups. To use a role to create a security policy, the role must be defined for the Role Mapping provider that is configured for that service module. All security policy data are stored in the policy database. When the Authorization provider is configured, its configuration is also stored in the policy database.

Note: Although you have the option of basing a security policy on a user or group, BEA recommends basing security policies on roles. Basing security policies on security roles is a more efficient method of management.

## ContextHandlers

A ContextHandler is a high-performing class that obtains additional context and container-specific information from the resource container, and provides that information to security providers making access or role mapping decisions. The ContextHandler interface provides a way for an internal resource container to pass additional information to a Security Framework call, so that a security provider can obtain contextual information beyond what is provided by the arguments to a particular method. A ContextHandler is essentially a name/value list and, as such, it requires that a security provider know what names to look for. In other words, use of a ContextHandler requires close cooperation between the resource and the security provider. Each name/value pair in a ContextHandler is known as a context element and is represented by a Context Element object.

For example, with WebLogic Server 8.1, three types of resource containers pass Context Handlers to the Security Framework: the Servlet, EJB, and Web Service containers. Thus, URL (web), EJB, and Web Service resource types have different context elements whose values Authorization and Role Mapping providers can inspect. An implementation of the Audit Context interface (used when a security provider is implemented to post audit events) may also examine the values of context elements.

## Adjudication

Adjudication involves resolving any authorization conflicts that may occur when more than one Authorization provider is configured in a policy domain, by weighing the result of each Authorization provider's access decision. An Adjudication provider tallies the results that multiple access decisions return, and determines the final `PERMIT` or `DENY` decision. An Adjudication provider may also specify what to do when an answer of `ABSTAIN` is returned from an access decision from a single Authorization provider.

### Adjudication Service

If there are multiple Authorization providers configured, the Security Framework delegates the job of reconciling any conflicts in the access decisions rendered by the Authorization providers to the Adjudication provider, which determines the ultimate outcome of the access decision. The Adjudication provider returns either a `TRUE` or `FALSE` verdict to the Authorization providers, and then forwards it to the resource through the Security Framework.

# Auditing

In the BEA WebLogic Enterprise Security architecture, an Auditing provider is used to support auditing services, for example, using the Log4j Auditing Channel provider. An auditing service is used to collect all security event information and distribute that information as configured.

If configured, the Security Framework calls the Auditing provider before and after security operations are performed (such as authentication or authorization), enabling audit event recording. The decision to audit a particular event is made by the Auditing provider itself and can be based on specific audit criteria and severity levels. The records that contain the audit information may be written to output repositories such as an LDAP server, a database, or a file.

## Auditing Service

An auditing service is a process whereby information about service requests and the outcome of those requests are made available to configured auditing providers. Auditing provides an electronic trail of transaction activity, and can include changes to system configuration parameters, policy changes, transactions, and security breach attempts of any type. For each audit item, the information may include who, what, when, where, and sometimes why.

Records can be directed to a file, a database or other persistent storage medium, and then used to generate reports from any reporting generating software you choose. Figure 3-10 shows how the Auditing provider interacts with the Security Framework and other types of security providers using a Authentication provider as an example.

The auditing process is initiated when a resource container passes authentication information for a user (for example, a username and password combination) to the Security Framework as part of a login request. The Security Framework passes the information associated with the login request to the configured Authentication provider. The Authentication provider passes the audit event back through the Security Framework, which then makes that audit event available to the configured Auditing provider.

Figure 3-10 Auditing Service Example for Authentication

# Credential Mapping

Credential mapping is the process of looking up the authentication credentials associated with a user for a given resource.

## Credential Mapping Service

The Credential Mapping service provides authentication credentials for a user of another application, for example, some type of mainframe transaction processing, a database system, or a legacy application. Three Credential Mapping providers are supplied: one supports usernames and passwords stored in a relational database; one supports usernames and passwords stored in a WebLogic Server 8.1 embedded LDAP directory (this provides support for WebLogic Portal 8.1); and one produces SAML credentials.

Figure 3-11 illustrates how the Credential Mapping provider interacts with the Security Framework to support the credential mapping service.

Figure 3-11 Credential Mapping Service

# Security Service Providers

Security services are based on a set of Security Service Provider Interfaces (SSPIs). Developers and third-party vendors can use the SSPIs to develop custom security providers for BEA WebLogic Enterprise Security. SSPIs are available for Authorization, Role Mapping and Adjudication; Auditing; Authentication, Principal Validation and Identity Assertion; and Credential Mapping (for a description of providers, see Table 3-1). The SSPIs allow customers to use their security providers to secure resources. Customers can use the SSPIs to develop custom security providers or they can purchase customer security providers from third-party vendors.

Table 3-1 Security Providers

Provider Type | Provider Name | Description
--- | --- | ---
WebLogic Enterprise Security Providers
Authentication | Windows NT Authentication Provider | Supports Microsoft Windows NT authentication.
| Active Directory Authentication Provider | Supports external LDAP authentication.
| Netscape Authentication Provider | Supports external LDAP authentication.
| Novell Authentication Provider | Supports external LDAP authentication.
| OpenLDAP Authentication Provider | Supports external LDAP authentication.
| Database Authentication Provider | Supports authentication through a relational database.
Identity Assertion | X.509 Identity Assertion Provider | Supports identity assertion through an X.509 digital certificate (ASN.1 encoding and decoding).
| SAML Identity Assertion Provider | Supports identity assertion through Security Assertion Markup Language v1.0.
| Single Pass Negotiate Identity Asserter | Supports identity assertion using HTTP authentication tokens from the SPNEGO protocol. The provider supports the identity assertion using the Kerberos tokens contained within the SPNEGO token.
| ALES Identity Assertion Provider | Supports identity assertion through an ALES cookie.
Credential Mapping | Database Credential Mapping Provider | Provides authentication credentials for a user (username and password) from a database for use in another application.
| SAML Credential Mapping Provider | Provides authentication credentials for a user (a SAML assertion) for use in another application.
| ALES Credential Mapping Provider | Provides authentication credentials for a user (a ALES cookie) for use in another application.
Auditing | Log4j Audit Channel Provider | Provides auditing features that support the Apache Log4j capabilities.
| Resource Deployment Audit Provider | Publishes WebLogic resources to the Administration Application.
Authorization | Authorization Provider | Provides enforcement of authorization for the policy with which it is used. The Authorization Provider returns an access decision that determines which resources are protected and if a particular user is allowed access to a resource.
| Adjudication Provider | Provides an authorization decision based on results from one or more authorization providers.
Role Mapping | Role Mapping Provider | Provides assignment to roles based on the security policy with which it is used. The Role Mapping Provider returns a set or roles granted to a user on a protected resource.
WebLogic Server 8.1 Providers
| WebLogic Authentication Provider | Supports authentication through an embedded LDAP Directory for WebLogic Server.
| WebLogic Authorization Provider | Provides enforcement of authorization for the security policy in WebLogic Server. The Authorization Provider returns an access decision that determines which resources are protected and if a particular user is allowed access to a resource.
| WebLogic Role Mapping Provider | Provides assignment to roles based on the security policy defined for use with WebLogic Server 8.1. The WebLogic Role Provider returns a set or roles granted to a user on a protected resource.
| WebLogic Credential Mapping Provider | Provides authentication credentials for a user (username and password) for single sign-on use into another application or resource.

Note: To assist customers in developing custom security providers, sample custom security providers are also available from the BEA dev2dev web site at http://dev2dev.bea.com. For more information on developing custom security providers, see Developing Security Providers for BEA WebLogic Enterprise Security.