Understanding WebLogic Security

WebLogic Security Service Architecture

This section provides a description of the architecture of the WebLogic Security Service. The architecture comprises three major components, which are discussed in the following sections:

WebLogic Security Framework

Figure 5-1 shows a high-level view of the WebLogic Security Framework. The framework comprises interfaces, classes, and exceptions in the weblogic.security.service package.

Figure 5-1 WebLogic Security Service Architecture

The primary function of the WebLogic Security Framework is to provide a simplified application programming interface (API) that can be used by security and application developers to define security services. Within that context, the WebLogic Security Framework also acts as an intermediary between the WebLogic containers (Web and EJB), the Resource containers, and the security providers.

The following sections describe the interactions between the WebLogic containers and Resource containers and each of the security providers via the WebLogic Security Framework:

The Authentication Process

Figure 5-2 shows the authentication process for a fat-client login. JAAS runs on the server to perform the login. Even in the case of a thin-client login (that is, a Web browser client) JAAS is still run on the server.

Figure 5-2 The Authentication Process

The Authentication Process

Notes: Only developers of custom Authentication providers will be involved with this JAAS process directly. The client application could either use a JNDI Initial Context or JAAS to initiate the passing of the username and password.

When a user attempts to log into a system using a username/password combination, WebLogic Server establishes trust by validating that user's username and password, and returns a subject that is populated with principals per JAAS requirements. As Figure 5-2 also shows, this process requires the use of a LoginModule and a Principal Validation provider. For more information on Principal Validation providers, see WebLogic Principal Validation Provider.

After successfully proving a caller's identity, an authentication context is established, which allows an identified user or system to be authenticated to other entities. Authentication contexts may also be delegated to an application component, allowing that component to call another application component while impersonating the original caller.

The Identity Assertion Process

Identity Assertion providers are used as part of perimeter authentication process. When perimeter authentication is used (see Figure 5-3), a token from outside of the WebLogic Server domain is passed to an Identity Assertion provider in a security realm that is responsible for validating tokens of that type and that is configured as "active." If the token is successfully validated, the Identity Assertion provider maps the token to a WebLogic Server username, and sends that username back to WebLogic Server, which then continues the authentication process. Specifically, the username is sent via a JAAS CallbackHandler and passed to each configured Authentication provider's LoginModule, so that the LoginModule can populate the subject with the appropriate principals.

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.

Figure 5-3 Perimeter Authentication

Perimeter Authentication

As Figure 5-3 also shows, perimeter authentication requires the same components as the authentication process, but also adds an Identity Assertion provider.

The Principal Validation Process

As shown in Figure 5-4, a user attempts to log into a system using a username/password combination. WebLogic Server establishes trust by calling the configured Authentication provider's LoginModule, which validates the user's username and password and returns a subject that is populated with principals per JAAS requirements.

Figure 5-4 The Principal Validation Process

The Principal Validation Process

WebLogic Server passes the subject to the specified Principal Validation provider, which signs the principals and then returns them to the client application via WebLogic Server. Whenever the principals stored within the subject are required for other security operations, the same Principal Validation provider will verify that the principals stored within the subject have not been modified since they were signed.

The Authorization Process

Figure 5-5 illustrates how Authorization providers (and the associated Adjudication and Role Mapping providers) interact with the WebLogic Security Framework during the authorization process.

Figure 5-5 Authorization Process

Authorization Process

The authorization process is initiated when a user or system process requests a WebLogic resource on which it will attempt to perform a given operation. The resource container that handles the type of WebLogic resource being requested receives the request (for example, the EJB container receives the request for an EJB resource). The resource container calls the WebLogic Security Framework and passes in the request parameters, including information such as the subject of the request and the WebLogic resource being requested. The WebLogic Security Framework calls the configured Role Mapping providers and passes in the request parameters in a format that the Role Mapping providers can use. The Role Mapping providers use the request parameters to compute a list of roles to which the subject making the request is entitled and passes the list of applicable roles back to the WebLogic Security Framework. The Authorization provider determines whether the subject is entitled to perform the requested action on the WebLogic resource, that is, the Authorization provider makes the Access Decision. If there are multiple Authorization providers configured, the WebLogic Security Framework delegates the job of reconciling any conflicts in the Access Decisions rendered by the Authorization providers to the Adjudication provider and the Adjudication provider determines the ultimate outcome of the authorization decision.

The Adjudication Process

If there are multiple Authorization providers configured (see Figure 5-5), an Adjudication provider is required to tally the multiple Access Decisions and render a verdict. The Adjudication provider returns either a TRUE or FALSE verdict to the Authorization providers, which forward it to the resource container through the WebLogic Security Framework.

If the decision is TRUE, the resource container dispatches the request to the protected WebLogic resource.
If the decision is FALSE, the resource container throws a security exception that indicates that the requestor was not authorized to perform the requested access on the protected WebLogic resource.

The Role Mapping Process

The WebLogic Security Framework calls each Role Mapping provider that is configured for a security realm as part of an authorization decision. For related information, see The Authorization Process.

Figure 5-6 shows how the Role Mapping providers interact with the WebLogic Security Framework to create dynamic role associations.

Figure 5-6 Role Mapping Process

Role Mapping Process

The role mapping process is initiated when a user or system process requests a WebLogic resource on which it will attempt to perform a given operation. The resource container that handles the type of WebLogic resource being requested receives the request (for example, the EJB container receives the request for an EJB resource). The resource container calls the WebLogic Security Framework and passes in the request parameters, including information such as the subject of the request and the WebLogic resource being requested. The WebLogic 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, 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 WebLogic resource or the resource container have been evaluated. The list of roles is returned to the WebLogic Security 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 providers) is a set of roles that apply to the principals stored in a subject at a given moment. These roles can then be used to make authorization decisions for protected WebLogic resources, as well as for resource container and application code. For example, an Enterprise JavaBean (EJB) could use the Java 2 Enterprise Edition (J2EE) isCallerInRole method to retrieve fields from a record in a database, without having knowledge of the business policies that determine whether access is allowed.

The Auditing Process

Figure 5-7 shows how Auditing providers interact with the WebLogic Security Framework and other types of security providers (using an Authentication provider as an example).

Figure 5-7 Auditing Process

Auditing Process

The auditing process is initiated when a resource container passes a user's authentication information (for example, a username/password combination) to the WebLogic Security Framework as part of a login request. The WebLogic Security Framework passes the information associated with the login request to the configured Authentication provider. If, in addition to providing authentication services, the Authentication provider is designed to post audit events, the Authentication provider instantiates an AuditEvent object. The AuditEvent object includes information such as the event type to be audited and an audit severity level. The Authentication provider then calls the Auditor Service in the WebLogic Security Framework, passing in the AuditEvent object. The Auditor Service passes the AuditEvent object to the configured Auditing providers' runtime classes, enabling audit event recording. The Auditing providers' runtime classes use the information obtained from the AuditEvent object to control audit record content. When the criteria for auditing specified by the Authentication providers in the AuditEvent object is met, the appropriate Auditing provider's runtime class writes out audit records. Depending on the Auditing provider implementation, audit records may be written to a file, a database, or some other persistent storage medium.

The Credential Mapping Process

Figure 5-8 illustrates how Credential Mapping providers interact with the WebLogic Security Framework during the credential mapping process.

Figure 5-8 Credential Mapping Process

Credential Mapping Process

The credential mapping process is initiated when application components, such as JavaServer Pages (JSPs), servlets, Enterprise JavaBeans (EJBs), or Resource Adapters call into the WebLogic Security Framework (through the appropriate resource container) to access an Enterprise Information System (EIS), for example, some relational database like Oracle, SQL Server, and so on. As part of the call, the application component passes in the subject (that is, the "who" making the request), the WebLogic resource (that is, the "what" that is being requested) and information about the type of credentials needed to access the WebLogic resource. The WebLogic Security Framework sends the application component's request for credentials to a configured Credential Mapping provider that handles the type of credentials needed by the application component. The Credential Mapping provider consults its database to obtain a set of credentials that match those requested by the application component and returns the credentials to the WebLogic Security Framework. The WebLogic Security Framework passes the credentials back to the requesting application component through the resource container. The application component uses the credentials to access the external system.

The Certificate Lookup and Validation Process

During the certificate lookup and validation process, CertPath Builders, CertPath Validators, and the Certificate Lookup and Validation (CLV) framework all interact.

The process for building certificate chains works as follows:

The CLV framework is passed a certificate chain and a cert path selector (either the end certificate, the Subject DN, the Issuer DN plus serial number, and/or the subject key identifier) from either a WebLogic Web service or application code.

The CLV framework calls the CertPath Builder to locate the certificate chain and validate it. When using Web services, the CLV framework passes the server's list of trusted CAs to the provider. Application code passes in a list of trusted CAs to the provider.

If the certificate chain is found and valid, the CLV framework calls any CertPath Validators configured in the security realm the order they were configured.

The certificate chain is only valid if the CertPath Builder and all the configured CertPath Validators successfully validate it.

The CLV framework returns the certificate chain to the requesting party.

Processing continues.

The process for validating certificate chains works as follows:

The CLV framework ensures calls the certificate chain is ordered and each certificate in the chain signs the next.

If the certificate chain is valid, the CLV framework calls any CertPath Validators configured in the security realm the order they were configured.

The certificate chain is only valid if all the configured CertPath Validators successfully validate it. Validation stops if an error occurs.

The CLV framework returns the certificate chain to the requesting party.

Processing continues.

Single Sign-On with the WebLogic Security Framework

The SAML and Windows Integrated Login features provide web-based single sign-on functionality for WebLogic Server applications. The following sections describe the interactions between the WebLogic containers, the security providers, and the WebLogic Security Framework during the single sign-on process.

WebLogic Server Acting a SAML Source Site

Acting as a SAML source involves the following:

Generating valid SAML assertions that assert that a source domain has authenticated a user and provide the name by which the user is known at the SAML source site. Optionally, the names of the local (source site) groups that the user is a member of are provided.
Providing a SAML ITS and a SAML Assertion Retrieval Service (ARS)

WebLogic Server can act as a SAML ITS and ARS. These services are provided by a servlet that is deployed based on configuration settings on the Server -> Configuration -> Federated Services Administrative Console pages.

The SAML ITS service requires separate URLs for the POST and Artifact profiles for V1 SAML providers; separate URLs are not required for the POST and Artifact profiles with V2 SAML providers.

The following sections detail how WebLogic Server is used as a SAML source in the POST and Artifact profiles.

POST Profile

The POST profile works as follows:

The user accesses the web site (for example, http://www.weblogic.com/samlits/its) for the SAML source site.

The SAML ITS servlet calls the SAML Credential Mapper to request a bearer assertion.

The SAML Credential Mapping provider returns the assertion. The SAML Credential Mapping provider also returns the URL of the SAML destination site and the path to the appropriate POST form.

The SAML ITS servlet generates a signed SAML response containing the generated assertion, signs it, based64-encodes it, and embeds it in the HTML form (default or custom).

The SAML ITS servlet returns the form to the user's browser.

The user's browser POSTs the form to the destination site's ACS.

The assertion is validated and if successful, the user is logged in and redirected to the target.

Artifact Profile

The Artifact profile works as follows:

The user accesses the web site (www.weblogic.com) for the SAML source site.

The SAML Inter-site Transfer Service (ITS) servlet calls the SAML Credential Mapper to request an assertion, passing in the desired assertion type (artifact).

The SAML Credential Mapping provider returns the assertion. The SAML Credential Mapping provider also returns the destination Assertion Consumer Service (ACS) URL and the assertion ID.

The SAML ITS servlet generates an artifact based on the assertion ID and the local source site's source ID. (This value is calculated from the Source Site URL configured on the Federation Services Source Site page.)

The SAML ITS servlet redirects the user to the Assertion Consumer Service (ACS) of the SAML source site, passing the artifact as a query parameter.

The ACS gets the artifact from the query parameter and decodes it to get the source ID. It then uses the source ID to look up the URL of the Assertion Retrieval Service (ARS) of the SAML source site. The ACS then sends a request to the URL of the ARS of the SAML source site requesting the assertion corresponding to the artifact.

The SAML Assertion Retrieval Service (ARS) responds to the incoming assertion request, using the artifact to locate the corresponding assertion in its assertion store, and if found, returning the assertion to the SAML destination site.

The assertion is validated and if successful, the user is logged in and redirected to the target.

Weblogic Server Acting as SAML Destination Site

WebLogic Server acts as a SAML destination site when an unauthenticated Web browser or HTTP client tries to access a protected WebLogic resource and SAML is configured as the authentication mechanism in the security realm.

The SAML destination site is implemented as a servlet authentication filter (referred to as the SAML authentication filter) deployed by the SAML Identity Assertion provider based on its configuration. The SAML destination site listens for incoming assertions at one or more configured URLs.These URLs provide the Access Consumer Service (ACS). The SAML destination site can also be configured to redirect unauthenticated users to remote SAML source sites for authentication based on the particular URL they tried to access.

The following sections detail how WebLogic Server is used as a SAML destination in the POST and Artifact profiles.

POST Profile

The POST profile works as follows:

The user accesses the web site (for example, http://www.weblogic.com/samlits/its) for the SAML source site.

The SAML source site authenticates the user, generates an assertion, and returns a POST form containing the assertion in a signed SAML response to the user's browser.

The user's browser posts the POST form to the ACS at the SAML destination site. The ACS looks for an asserting party ID (APID) as a form parameter of the incoming request, and uses this to look up the configuration before performing any other processing.

Upon receiving a POST form from the SAML source site, the SAML destination site extracts the embedded SAML response from the POST form and verifies trust in the certificate used to sign the response. An optional recipient check may be performed depending on the configuration.

The SAML Authentication filter also ensures that this assertion has not been previously used. If the one-use check is configured, the filter checks to see if the assertion has already been used. If so, the filter returns an error. If not, the filter persists the assertion to enable future checks.

One of the following then occurs:

If the one-use check or any other validity/trust check fails, the login fails and WebLogic Server returns a 403 Forbidden.
If the one-use check and any other validity/trust checks are successful, the user is logged in (by the assertIdentity() call). The SAML authentication filter creates a session for the user and redirects the now authenticated user to the requested target URL.

Artifact Profile

The Artifact profile works as follows:

The user accesses the web site (for example, http://www.weblogic.com/samlits/its) for the SAML source site.

The request is redirected to the SAML ITS service.

The SAML source site authenticates user.

After the user is authenticated, the SAML ITS generates an assertion and then generates a base-64 encoded artifact that contains the assertion ID and the source ID of the SAML ITS.

The SAML ITS redirects the user to the Assertion Consumer Service (ACS) of the SAML destination site, passing the artifact as a query parameter on the redirect URL. The ACS looks for an asserting party ID (APID) as a query parameter of the incoming request, and uses this to look up the configuration before performing any other processing. The ACS gets the artifact by looking for the query parameter.

The SAML authentication filter base64-decodes the artifact to determine the source ID of the SAML source site and the assertion ID. The source ID is used to look up the Assertion Retrieval URL for that source site. The filter then makes a SOAP request to the Artifact Retrieval Service (ARS) at the SAML source site, sending the artifact and requesting the corresponding assertion.

The SAML source site returns an assertion.

The SAML authentication filter calls the PrincipalValidator to assert the user's identity.

One of the following then occurs:

If any validity/trust check fails, the login fails and WebLogic Server returns a 403 Forbidden.
If all validity/trust checks are successful, the user is logged in (by the assertIdentity() call). The SAML authentication filter creates a session for the user and redirects the now authenticated user to the requested target URL.

Desktop SSO Process

The process works as follows:

The Negotiate Identity Assertion provider is configured to support the WWW-Authenticate and Authorization HTTP headers. The Negotiate Identity Assertion provider uses a servlet authentication filter to generate the appropriate WWW-Authenticate header on unauthorized responses for the negotiate protocol and handles the Authorization headers on subsequent requests.

A user logs into the Windows 2000 or 2003 domain. The user acquires Kerberos credentials from the domain.

Using a browser that supports the SPNEGO protocol (for example, Internet Explorer or Mozilla), the user tries to access a Web Application running on an application server. The application server can be running on a UNIX or Windows 2000/2003 platform.

The browser sends a GET request to the application server.

The application server sends back an unauthorized response with the appropriate WWW-Authenticate headers.

The Servlet container gets the configured chain of servlet authentication filters from the WebLogic Security Framework.

The Servlet container calls the chain of servlet authentication filters. The Negotiate servlet authentication filter adds the WWW-Authenticate request header for the negotiate authentication scheme and calls into the WebLogic Security Framework to get the initial Negotiate challenge. The following message is sent back:

401 Unauthorized WWW-Authenticate: Negotiate

The browser receives the WWW-Authenticate header and determines whether or not it can support the Negotiate authentication scheme. The browser then creates a SPNEGO token containing the supported GSS mechanism token types. It Base64 encodes the token and sends it back to the application server via an Authorization header on the original GET message as follows:

GET... Authorization: Negotiate <Base64 encoded SPNEGO token>

Since the request is still unauthorized, the Servlet container calls the servlet authentication filters. The Negotiate servlet authentication filter handles the Authorization request header and calls the WebLogic Security Framework. The framework passes the token to the Negotiate Identity Assertion provider.

The Negotiate Identity Assertion provider uses the GSS context to get the name of the initiating Principal. This name is mapped to a username and passed back to the WebLogic Security framework via a Callback handler.

The WebLogic Security framework also determines to which groups the user belongs.

The authentication is complete and the GET request is processed.

SAML Token Profile Support in WebLogic Web Services

The WebLogic Web Services and the WebLogic Security framework have been enhanced to support the generation, consumption, and validation of SAML assertions. When using SAML assertion, a Web Service passes an SAML assertion and the accompanying proof material to the WebLogic Security framework. If the SAML assertion is valid and trusted, the framework returns an authenticated Subject with a trusted principal back to the Web service. WebLogic Web Services and the WebLogic Security framework support the following SAML assertions:

Sender-Vouches—The asserting party (different from the subject) vouches for the verification of the subject. The receiver must have a trust relationship with the asserting party.
Holder-of-Key—The purpose of SAML token with "holder-of-key" subject confirmation is to allow the subject to use an X.509 certificate that may not be trusted by the receiver to protect the integrity of the request messages.

Conceptually, the asserting party inserts an X.509 public certificate (or other key info) into a SAML assertion. (More correctly, the asserting party binds a key to a subject.) In order to protect this embedded certificate, the SAML assertion itself must be signed by the asserting entity. For WebLogic Server, the Web Service client signs the SAML assertion with its private key. That is, the signature on the assertion is the signature of the SAML authority, and is not based on the certificate contained in, or identified by, the assertion.

The following sections describe how the processing of these assertions work.

Sender-Vouches Assertions

All the Sender-Vouches assertions are basically the same, the difference is in how trust is established (meaning whether or not SSL is used for transport and whether or not the SAML assertion and the message bodies are signed).

The Sender-Vouches assertions are used in the following manner:

A user invokes a WebLogic Web Service.

The Web Service requests a SAML assertion from the user.

The user generates a SAML assertion and returns it to the Web Service.

The Web Service calls the SAML Credential Mapping provider which generates an appropriate SAML assertion.

One of the following occurs. Note that this list represents the most likely scenarios and that other scenarios are possible.

The Web Service sends an unsigned assertion and uses a non-SSL transport in a SOAP message to the destination. With this type of assertion, there is no proof material in the SOAP message so the assertion cannot be trusted nor can it be assumed that the assertion came from a trusted party.
The Web Service uses the SSL protocol to send an unsigned assertion in a SOAP message to the destination. With this type of assertion, the client certificate is used to establish trust.
The Web Service signs the assertion and sends it using a non-SSL transport in a SOAP message to the destination. With this type of assertion, the signature provides the proof material for trust but it can't be assumed that the connection was not compromised. However, modification of a signed assertion can be detected because any change will break the signature
The Web Service signs the assertion and uses the SSL protocol to send the signed assertion in a SOAP message to the destination. With this type of assertion, trust is established either through the signature or the client certificate.

The SAML Identity Assertion provider consumes and validates the assertion and determines if the assertion is to be trusted.

If the assertion is to be trusted, the SAML Identity Assertion provider creates a Subject containing user principals and possibly group principals and returns the Subject with principals to the Web Service.

The Web Service returns the response to the user.

Holder-of-Key Assertion

In the Holder-of-Key assertion, the Web Service client depends on the Web Service server to ensure that the user is to be trusted.

The Holder-of-Key assertions are used in the following manner:

A user authenticates to a Web Service client through some undetermined mechanism. The Web Service client can be local or remote and may or may not be a WebLogic server instance.

The Web Service client trusts the user, generates a SAML assertion containing the certificate of the user, and signs the SAML assertion with its private key. The Web Service client returns the SAML assertion to the user.

The user inserts the SAML assertion information into a wsse:Security header in a SOAP message. The message body is signed with the private key of the user.

The user invokes a WebLogic Web Service.

The Web Service sends the SOAP message to the Web Service server (in this case, a WebLogic Server instance). The Web Service server makes a trust decision based on whether or not it trusts the SAML assertion and the SOAP message.

The Web Services server receives the assertion and passes it to the SAML Identity Asserter. The SAML Identity Asserter verifies the assertion signature and verifies trust in the certificate used for that signature.

If this succeeds, the Web Service server can assume that the key in the holder-of-key assertion does in fact belong to the Subject of the assertion. Web Services can then use that key to verify the signature that signs the SOAP message, which establishes that the SOAP message was generated/sent by the holder of the key. It is up to the Web Service server to verify trust in the X.509 certificate itself.

The Web Service server returns a Subject with principals for the SAML assertion to the Web Service client.

The Web Service client returns the response to the user.

Optionally, the SSL protocol can be used with this assertion. If the SSL protocol is used, the client certificate can also be used as proof material.

The Security Service Provider Interfaces (SSPIs)

Security in this release of WebLogic Server is based on a set of Security Service Provider Interfaces (SSPIs). The SSPIs can be used by developers and third-party vendors to develop security providers for the WebLogic Server environment. SSPIs are available for Adjudication, Auditing, Authentication, Authorization, Credential Mapping, Identity Assertion, Role Mapping, and Certificate Lookup and Validation.

Note: The SSPI for Keystore providers is deprecated in this release of WebLogic Server. Use Java KeyStores (JKS) instead. For information on how to use Java KeyStores, see Confuring Keystores in Securing WebLogic Server.

The SSPIs allow customers to use custom security providers for securing WebLogic Server resources. Customers can use the SSPIs to develop custom security providers or they can purchase customer security providers from third-party vendors.

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

Weblogic Security Providers

This section provides descriptions of the security providers that are included in the WebLogic Server product for your use. Security providers are modules that "plug into" a WebLogic Server security realm to provide security services to applications. They call into the WebLogic Security Framework on behalf of applications.

If the security providers supplied with the WebLogic Server product do not fully meet your security requirements, you can supplement or replace them with custom security providers. You develop a custom security provider by:

Implementing the appropriate security service provider interfaces (SSPIs) from the weblogic.security.spi package to create runtime classes for the security provider.
Creating an MBean Definition File (MDF) and using the WebLogic MBeanMaker utility to generate an MBean type, which is used to configure and manage the security provider.

For more information, see Developing Security Providers for WebLogic Server.

Figure 5-9 shows the security providers that are required and those that are optional in a WebLogic security realm.

Figure 5-9 WebLogic Security Providers

WebLogic Security Providers

The security providers are described in the following sections:

WebLogic Authentication Provider

The default (active) security realm for WebLogic Server includes a WebLogic Authentication provider. The WebLogic Authentication provider supports delegated username/password and WebLogic Server security digest authentication. It utilizes an embedded LDAP server to store user and group information. This provider allows you to edit, list, and manage users and group membership.

Note: In conjunction with the WebLogic Authorization provider, the WebLogic Authentication provider replaces the functionality of the File realm that was available in 6.x releases of WebLogic Server.

Alternative Authentication Providers

WebLogic Server provides the following additional Authentication providers which can be used instead of or in conjunction with the WebLogic Authentication provider in the default security realm:

A set of LDAP Authentication providers that access external LDAP stores (Open LDAP, Netscape iPlanet, Microsoft Active Directory, and Novell NDS).
A set of Database Base Management System (DBMS) authentication providers that access user, password, group, and group membership information stored in databases for authentication purposes. Optionally, WebLogic Server can be used to manage the user, password, group, and group membership information. The DBMS Authentication provider are the upgrade path from the RDBMS security realm.

The following DBMS Authentication providers are available:

SQL Authentication provider—A manageable authentication provider that supports the listing and editing of user, password, group, and group membership information.
Read-only SQL Authentication provider—An authentication provider that supports authentication of users in a database and the listing of the contents of the database through the WebLogic Server Administration Console. The authentication provider requires a specific set of SQL statements so it might not meet all customer needs.
Custom DBMS Authentication provider—A run-time authentication provider that only supports authentication. This provider require customer-written code that handles querying the database to obtain authentication information.This authentication provider is a flexible alternative that allows customer to adapt a DBMS Authentication provider to meet their special database needs.

A Windows NT Authentication provider that uses Windows NT users and groups for authentication purposes. The Windows NT Authentication provider is the upgrade path for the Window NT security realm. The Windows NT users and groups are displayed through the WebLogic Server Administration Console however, they cannot be managed through the console.
An LDAP X509 Identity Assertion provider that looks up the LDAP object for the user associated with an X509 certificate, ensures that the certificate in the LDAP object matches the presented certificate, and then retrieves the name of the user from the LDAP object for the purpose of authentication.

Note: By default, these additional Authentication providers are available but not configured in the WebLogic default security realm.

WebLogic Identity Assertion Provider

The WebLogic Identity Assertion provider supports certificate authentication using X.509 certificates and CORBA Common Secure Interoperability version 2 (CSIv2) identity assertion. The WebLogic Identity Assertion provider validates the token type, then maps X.509 digital certificates and X.501 distinguished names to WebLogic users. It also specifies a list of trusted client principals to use for CSIv2 identity assertion. The wildcard character (*) can be used to specify that all principals are trusted. If a client is not listed as a trusted client principal, the CSIv2 identity assertion fails and the invoke is rejected.

The WebLogic Identity Assertion provider supports the following token types:

AU_TYPE—for a WebLogic AuthenticatedUser used as a token.
X509_TYPE—for an X.509 client certificate used as a token.
CSI_PRINCIPAL_TYPE—for a CSIv2 principal name identity used as a token.
CSI_ANONYMOUS_TYPE—for a CSIv2 anonymous identity used as a token.
CSI_X509_CERTCHAIN_TYPE—for a CSIv2 X.509 certificate chain identity used as a token.
CSI_DISTINGUISHED_NAME_TYPE—for a CSIv2 distinguished name identity used as a token.
WSSE_PASSWORD_DIGEST—for a wsse:UsernameToken with a password type of wsse:PasswordDigest used as a token.

SAML Identity Assertion Provider

The SAML Identity Assertion provider validates SAML 1.1 assertions and verifies the issuer is trusted. If so, identity is asserted based on the AuthenticationStatement contained in the assertion.

Provider configuration includes settings that configure and enable SAML source site and destination site SSO services (such as ITS, ACS, and ARS) to run in the server.

The SAML Identity Assertion provider supports the following SAML Subject confirmation methods:

artifact
bearer
sender-vouches
holder-of-key

Negotiate Identity Assertion Provider

The Negotiate Identity Assertion provider is used for SSO with Microsoft clients that support the SPNEGO protocol. Specifically, it decodes SPNEGO tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users. The Negotiate Identity Assertion provider utilizes the Java Generic Security Service (GSS) Application Programming Interface (API) to accept the GSS security context via Kerberos. For more information about the Java GSS API, see http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/jgss-features.html.

The Negotiate Identity Assertion provider interacts with the WebLogic Servlet container which handles WWW-Authenticate and WWW-Authorization headers, adding the appropriate Negotiate header.

By default, the Negotiate Identity Assertion provider is available but not configured in the WebLogic default security realm. The Negotiate Identity Assertion provider can be used instead of or in addition to the WebLogic Identity Assertion provider.

WebLogic Principal Validation Provider

The default (active) security realm for WebLogic Server includes a WebLogic Principal Validation provider. This provider signs and verifies WebLogic Server principals. In other words, it signs and verifies principals that represent WebLogic Server users or WebLogic Server groups.

Note: You can use the WLSPrincipals class (located in the weblogic.security package) to determine whether a principal (user or group) has special meaning to WebLogic Server (that is, whether it is a predefined WebLogic Server user or WebLogic Server group). Furthermore, any principal that is going to represent a WebLogic Server user or group needs to implement the WLSUser and WLSGroup interfaces (available in the weblogic.security.spi package).

The WebLogic Principal Validation provider includes implementations of the WLSUser and WLSGroup interfaces, named WLSUserImpl and WLSGroupImpl. These are located in the weblogic.security.principal package. It also includes an implementation of the PrincipalValidator SSPI called PrincipalValidatorImpl. For more information about the PrincipalValidator SSPI, see Implement the PrincipalValidator SSPI in Developing Security Providers for WebLogic Server.

Much as an Identity Assertion provider supports a specific type of token, a Principal Validation provider signs and verifies the authenticity of a specific type of principal. Therefore, you can use the WebLogic Principal Validation provider to sign and verify principals that represent WebLogic Server users or WebLogic Server groups.

WebLogic Authorization Provider

As of version 9.0.1, WebLogic Server includes an Authorization provider that supports the eXtensible Access Control Markup Language (XACML) 2.0 standard from OASIS. WebLogic This provider can import, export, persist and execute policy expressed using all standard XACML 2.0 functions, attributes, and schema elements.

New domains created using 9.0.1 will default to using the XACML Authorization provider. Existing domains, upgraded to 9.0.1, will continue to use the Authorization provider currently specified, such as third-party partner providers or the original WebLogic Server proprietary providers. If you use the WebLogic Server Administration Console to add a new Authorization provider, you can add the new provider as a DefaultAuthorizer or as a XACML provider.

Custom XACML providers are not supported in this release.

Version 9.0.1 of WebLogic Server also includes the "default" WebLogic Authorization provider. This provider supplied the default enforcement of authorization for versions of WebLogic Server prior to 9.0.1. Using a policy-based authorization engine, the WebLogic Authorization provider returns an access decision to determine if a particular user is allowed access to a protected WebLogic resource. The WebLogic Authorization provider also supports the deployment and undeployment of security policies within the system.

WebLogic Adjudication Provider

The default (active) security realm for WebLogic Server includes a WebLogic Adjudication provider. This provider would normally be responsible for tallying the potentially differing results rendered by multiple Authorization providers' Access Decisions and rendering a final verdict on whether or not access will be granted to a WebLogic resource. However, because the default security realm only has one Authorization provider, only one Access Decision is produced so the WebLogic Adjudication provider is not used.

Note: The WebLogic Adjudication provider is used in the Compatibility realm, which has two Authorization providers.

The WebLogic Adjudication provider has an attribute called Require Unanimous Permit that governs its behavior. By default, the Require Unanimous Permit attribute is set to TRUE, which causes the WebLogic Adjudication provider to act as follows:

If all the Authorization providers' Access Decisions return PERMIT, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).
If some Authorization providers' Access Decisions return PERMIT and others return ABSTAIN, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).
If any of the Authorization providers' Access Decisions return ABSTAIN or DENY, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).

If you change the Require Unanimous Permit attribute to FALSE, the WebLogic Adjudication provider acts as follows:

If all the Authorization providers' Access Decisions return PERMIT, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).
If some Authorization providers' Access Decisions return PERMIT and others return ABSTAIN, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).
If any of the Authorization providers' Access Decisions return DENY, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).

Note: You set the Require Unanimous Permit attributes when you configure the WebLogic Adjudication provider. For more information about configuring an Adjudication provider, see Configuring a WebLogic Adjudication Provider in Securing WebLogic Server.

WebLogic Role Mapping Provider

As of version 9.0.1, WebLogic Server includes a Role Mapping provider that supports the eXtensible Access Control Markup Language (XACML) 2.0 standard from OASIS. WebLogic This provider can import, export, persist and execute policy expressed using all standard XACML 2.0 functions, attributes, and schema elements.

New domains created using 9.0.1 will default to using the XACML Role Mapping provider. Existing domains, upgraded to 9.0.1, will continue to use the Role Mapping provider currently specified, such as third-party partner providers or the original WebLogic Server proprietary providers. If you use the WebLogic Server Administration Console to add a new Role Mapping provider, you can add the new provider as a DefaultRoleMapper or as a XACML provider.

Custom XACML providers are not supported in this release.

Version 9.0.1 of WebLogic Server also includes the "default" WebLogic Role Mapping provider. This provider supplied the default enforcement of role mapping for versions of WebLogic Server prior to 9.0.1. This provider determines dynamic roles for a specific user (subject) with respect to a specific protected WebLogic resource for each of the default users and WebLogic resources. The WebLogic Role Mapping provider supports the deployment and undeployment of roles within the system. The WebLogic Role Mapping provider uses the same security policy engine as the WebLogic Authorization provider.

WebLogic Auditing Provider

The default (active) security realm for WebLogic Server includes a WebLogic Auditing provider. This provider records information from a number of security requests, which are determined internally by the WebLogic Security Framework. The WebLogic Auditing provider also records the event data associated with these security requests, and the outcome of the requests.

WebLogic Credential Mapping Provider

The default (active) security realm for WebLogic Server includes a WebLogic Credential Mapping provider. You use the WebLogic Credential Mapping provider to associate, or map, a WebLogic Server user to the appropriate credentials to be used with a Resource Adapter to access an Enterprise Information System (EIS), for example, some relational database like Oracle, SQL Server, and so on. The provider maps a user's authentication credentials (username and password) to those required for legacy applications, so that the legacy application gets the necessary credential information. For example, the EIS may be a mainframe transaction processing, database systems, or legacy applications not written in the Java programming language.

If you only want to map WebLogic Server users and groups to username/password credentials in another system, then the WebLogic Credential Mapping provider is sufficient.

SAML Credential Mapping Provider

The SAML Credential Mapping provider generates SAML 1.1 assertions for authenticated subjects based on relying party/destination site configuration. Assertions contain an authentication statement and, optionally, an attribute statement containing WebLogic Server group information. If the requested target has not been configured and no defaults are set, an assertion will not be generated. User information and group membership (if configured as such) are put in the AttributeStatement.

The Administration Console Federation Services configuration pages include settings that configure and enable SAML source site and destination site SSO services (such as ITS, ACS, and ARS) to run in the server.

The provider supports the following SAML Subject confirmation methods:

artifact
bearer
sender-vouches
holder-of-key

PKI Credential Mapping Provider

The PKI (Public Key Infrastructure) Credential Mapping provider maps a WebLogic Server subject (the initiator) and target resource (and an optional credential action) to a public/private key pair or public certificate that should be used by the application when using the targeted resource. This provider can also map an alias to a public/private key pair or public certificate. The PKI Credential Mapping provider uses the subject and resource name, or the alias, to retrieve the corresponding credential from the keystore.

WebLogic CertPath Provider

The WebLogic CertPath provider is both a CertPath Builder and a CertPath Validator. The provider completes certificate paths and validates the certificates using the trusted CA configured for a particular server instance.If a certificate chain cannot be completed, it is invalid.

The WebLogic CertPath provider also checks the signatures in the chain, ensures that the chain has not expired, and checks that one of the certificates in the chain is issued by one of the trusted CAs configured for the server. If any of these checks fail, the chain is not valid.

Finally, the provider checks that the each certificate's basic constraints (that is, the ability of the certificate to issue other certificates) to ensure the certificate is in the proper place in the chain.

The WebLogic CertPath provider can be used as CertPath Builder or a CertPath Validator in a security realm.

Certificate Registry

The Certificate Registry allows the system administrator to explicitly configure a list of trusted CA certificates that are allowed access to the server. The Certificate Registry provides an inexpensive mechanism for performing revocation checking. An administrator revokes a certificate by removing it from the certificate registry. The registry is stored in the embedded LDAP server.

Certificate Registries are configured on a per domain basis rather than a per server basis.

The Certificate Registry is both a CertPath Builder and a CertPath Validator. In either case, the Certificate Registry ensures that the chain's end certificate is stored in the registry.

Versionable Application Provider

A versionable application is an application that has an application archive version specified in the manifest of the application archive (EAR file). Versionable applications can be deployed side-by-side and active simultaneously. Versionable applications allow multiple versions of an application, where security constraints can vary between the application versions.

The Versionable Application provider SSPI enables all security providers that support application versioning to be notified when versions are created and deleted. It also enables all security providers that support application versioning to be notified when non-versioned applications are removed.

WebLogic Keystore Provider

The WebLogic Keystore provider uses the reference keystore implementation supplied by Sun Microsystems in the Java Software Development Kit (SDK). It utilizes the standard Java KeyStore (JKS) keystore type, which implements the keystore as a file (one per machine). It protects each private key with its individual password. There are two keystore files associated with the WebLogic Keystore provider:

One keystore file holds the trusted certificate authority (CA) certificates. WebLogic Server also ships a trusted certificate authority Keystore file that it uses by default to locate the trusted CA certificates, which are then used in SSL to verify client certificates.
The other keystore file holds the server's private keys. WebLogic Server retrieves a private key from this file to initialize SSL. You can use the Sun Microsystems SDK keytool utility or the WebLogic Server ImportPrivateKey utility to add private keys to this file. Note that WebLogic Server can retrieve private keys and certificates from this keystore file.

Note: 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 Securing WebLogic Server.

WebLogic Realm Adapter Providers

The WebLogic 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 WebLogic 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. The following WebLogic Realm Adapter providers are provided:

Authentication (includes an Identity Assertion provider)

The Realm Adapter Authentication provider allows you to use version 6.x security realms and their data stores with the WebLogic security providers in WebLogic Server. The Realm Adapter Authentication provider also allows you to use implementations of the weblogic.security.acl.CertAuthenticator class with WebLogic Server. The Realm Adapter Authentication provider includes a component that provides identity assertion based on X.509 tokens.

Authorization

In Compatibility security, two types of Authorization providers are used: the WebLogic Authorization provider and the Realm Adapter Authorization provider. The WebLogic Authorization provider is used for new security policies. The Realm Adapter Authorization provider is used for mapping to WebLogic Server 6.1 access control lists (ACLs).

Auditing

The Realm Adapter Auditing provider allows you to use implementations of the weblogic.security.audit interface with WebLogic Server deployments using Compatibility security.

Adjudication

The Realm Adapter Adjudication provider enables both the WebLogic Authorization provider and the Realm Adapter Authorization provider to be used together for a security realm in Compatibility security.

Although these security providers are configured using the WebLogic Server Administration Console, your existing 6.x security realms will continue to use the same MBeans and user interface present in WebLogic Server 6.1.

Note: The WebLogic Realm Adapter providers are deprecated and should only be used while upgrading to the security model available in this release of WebLogic Server.