5 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

Description of Figure 5-1 follows
Description of "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

Description of Figure 5-2 follows
Description of "Figure 5-2 The Authentication Process"

Note:

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 either the default user name mapper that is supplied with the WebLogic Server product (weblogic.security.providers.authentication. DefaultUserNameMapperImpl) or your own implementation of the weblogic.security.providers.authentication.UserNameMapper interface. See "Do You Need to Develop a Custom Identity Assertion Provider?" in Developing Security Providers for Oracle WebLogic Server.

Figure 5-3 Perimeter Authentication

Description of Figure 5-3 follows
Description of "Figure 5-3 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

Description of Figure 5-4 follows
Description of "Figure 5-4 The Principal Validation Process"

WebLogic Server then passes the subject to the specified Principal Validation provider, which signs the principals and 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

Description of Figure 5-5 follows
Description of "Figure 5-5 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

Description of Figure 5-6 follows
Description of "Figure 5-6 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 EE 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).

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

Description of Figure 5-8 follows
Description of "Figure 5-8 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:

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

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

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

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

  5. Processing continues.

The process for validating certificate chains works as follows:

  1. 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 the SSL protocol, a WebLogic Web service, or application code.

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

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

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

  5. Processing continues.

Single Sign-On with the WebLogic Security Framework

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

Single Sign-On with SAML 1.1

The following sections describe how a WebLogic Server instance behaves during when configured with SAML 1.1 services:

WebLogic Server Acting a SAML 1.1 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 pages in the Administration Console.

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:

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

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

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

  4. 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).

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

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

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

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

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

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

  4. 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.)

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

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

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

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

Weblogic Server Acting as SAML 1.1 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

In a typical SSO scenario, the POST profile works as follows:

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

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

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

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

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

  6. 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:

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

  2. The request is redirected to the SAML ITS service.

  3. The SAML source site authenticates user.

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

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

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

  7. The SAML source site returns an assertion.

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

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

Single Sign-On and SAML 2.0

The SAML 2.0 Web Single Sign-On (SSO) profile supported by WebLogic Server implements the Authentication Request Protocol in conjunction with the HTTP Redirect, HTTP POST, and HTTP Artifact bindings. The following sections describe the flow of execution in both ways of that this profile can be initiated, showing the interaction among the SAML 2.0 services provided in WebLogic Server and the WebLogic Security Service:

Service Provider Initiated Single Sign-On

In a typical Service Provider initiated SSO scenario, an unauthenticated user tries to access a protected resource on a Service Provider site. In response, the Service Provider initiates a Web SSO session by identifying the appropriate Identity Provider partner and sending or redirecting an authentication request to that partner. The Identity Provider then authenticates the user, typically via a login web application, generates a SAML assertion containing that user's identity information, and returns the assertion to the Service Provider in the form of an authentication response.

When the Service Provider receives the authentication response, the Service Provider extracts the identity information from the assertion contained in the response and verifies the user's identity by mapping it to a Subject in the local security realm. If the user's identity is successfully mapped, the Service Provider can consequently authorize the user's access to the protected resource.

Figure 5-9 shows the flow of execution in an example of a Service Provider initiated Web single sign-on session.

Figure 5-9 Service Provider Initiated Single Sign-On

Description of Figure 5-9 follows
Description of "Figure 5-9 Service Provider Initiated Single Sign-On"

Note the following callouts in Figure 5-9 showing the flow of execution:

  1. From a web browser, a user attempts to access a protected resource running in a WebLogic container that is hosted by a Service Provider.

  2. The WebLogic container invokes the WebLogic Security Service to determine if the user is authenticated.

  3. Because the user is not authenticated, the Service Provider generates an authentication request that contains information about the unauthenticated user and sends it to the Identity Provider, using the endpoint of the Identity Provider's Single Sign-On Service.

    The Service Provider can be configured to use one of the following bindings for transmitting the authentication request:

    • HTTP POST - When using the HTTP POST binding, the Service Provider sends an HTTP POST message containing the authentication request to the user's browser. The HTTP POST message is then sent to the Identity Provider's Single Sign-On Service.

    • HTTP Artifact - The Service Provider sends an HTTP redirect message that includes a SAML artifact to the user's browser. The SAML artifact contains a pointer to the authentication request message, which is maintained by the Service Provider's Artifact Resolution Service (ARS). When the Identity Provider receives the HTTP redirect message, it sends an artifact resolution request to the Service Provider's ARS to obtain the authentication request message.

    • HTTP Redirect - The Service Provider sends an HTTP redirect message to the user's browser, which sends an HTTP GET message to the Identity Provider's Single Sign-On Service.

  4. The user is presented with a login web application hosted by an Identity Provider that is capable of authenticating that user. The Identity Provider challenges the user for his or her credentials.

  5. The user provides his or her username and password to the Identity Provider, which completes the authentication operation.

  6. The Single Sign-On Service hosted by the Identity Provider generates an assertion for the user and returns an authentication response to the Service Provider's Assertion Consumer Service (ACS).

    The Identity Provider can be configured to use the following bindings:

    • HTTP POST - The Identity Provider sends the authentication response, which contains the assertion, to the user's browser. The authentication response is transmitted to the Service Provider via an HTTP POST message.

    • HTTP Artifact - The Identity Provider sends an authentication response, which contains a SAML artifact, to the user's browser. The SAML artifact contains a pointer to the assertion, which is handled by the Identity Provider's Artifact Resolution Service (ARS). The authentication response is transmitted to the Service Provider via an HTTP redirect message.When the Service Provider receives the response, it sends an artifact resolution request to the Identity Provider's ARS to obtain the assertion.

      The ACS validates the assertion, extracts the identity information from that assertion, and maps that identity to a subject in the local security realm.

  7. The ACS sends an HTTP redirect message to the browser, passing a cookie containing a session ID and enabling the browser to access the requested resource.

    The WebLogic Security Service performs an authorization check to determine whether the browser may access the requested resource. If the authorization check succeeds, access to the resource is granted.

Identity Provider Initiated Single Sign-On

WebLogic Server also supports the scenario in which a web single sign-on session is initiated by an Identity Provider. In this scenario, a user is authenticated by an Identity Provider and issues a request on a resource that is hosted by a Service Provider. The Identity Provider initiates the SSO session by sending an unsolicited authentication response to the Service Provider.

When the Service Provider receives the authentication response, the Service Provider extracts the identity of the user from the assertion, maps that identity to a local subject, and performs an authorization check on the requested resource. If the authorization check succeeds, access is granted.

Figure 5-10 shows the flow of execution in a typical Identity Provider initiated SSO session.

Figure 5-10 Identity Provider Initiated Single Sign-On

Description of Figure 5-10 follows
Description of "Figure 5-10 Identity Provider Initiated Single Sign-On"

Note the following callouts in Figure 5-10 showing the flow of execution:

  1. The user is presented with a login web application hosted by an Identity Provider that authenticates the user. The Identity Provider challenges the user for his or her credentials.

  2. The user provides his or her username and password to the Identity Provider, which completes the authentication process.

    The user issues a request on a resource that is hosted by a Service Provider.

  3. The Single Sign-On Service hosted by the Identity Provider sends an unsolicited authentication response to the Service Provider to the Service Provider's Assertion Consumer Service (ACS).

    Regardless of how the SSO session is initiated, the Identity Provider uses the same bindings as described in Service Provider Initiated Single Sign-On.

  4. The ACS validates the assertion, extracts the identity information, and maps that identity to a subject in the local security realm. The ACS sends an HTTP redirect message to the browser, passing a cookie containing a session ID and enabling the browser to access the requested resource.

  5. The WebLogic Security Service performs an authorization check to determine whether the browser may access the requested resource. If the authorization check succeeds, access to the resource is granted.

Desktop SSO Process

The process works as follows:

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

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

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

  4. The browser sends a GET request to the application server.

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

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

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

    WWW-Authenticate: Negotiate

  8. 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>
    
  9. 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.

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

  11. 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 1.1 and 2.0 assertions. When using SAML assertions, a web service passes a 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.

  • Bearer - The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using attributes that may be included in the <SubjectConfirmationData> element of 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:

  1. A user invokes a WebLogic Web service.

  2. The Web service requests a SAML assertion from the user.

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

  4. The Web service calls the SAML Credential Mapping provider, which generates an appropriate SAML assertion.

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

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

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

  8. 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:

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

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

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

  4. The user invokes a WebLogic Web service.

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

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

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

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.

To assist customers in developing custom security providers, sample custom security providers are also available on the Oracle Technology Network (OTN).

For more information on developing custom security providers, see Developing Security Providers for Oracle 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 Oracle WebLogic Server.

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

Figure 5-11 WebLogic Security Providers

Description of Figure 5-11 follows
Description of "Figure 5-11 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.

This provider also provides a set of attributes, such as employee number and department number, that you can assign to users.

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, iPlanet, Microsoft Active Directory, Oracle Internet Directory, Oracle Virtual 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.

Password Validation Provider

WebLogic Server includes a Password Validation provider, which manages and enforces a set of password composition rules when configured with one or more of the following authentication providers:

  • WebLogic Authentication provider

  • SQL Authenticator provider

  • LDAP Authentication provider

  • Active Directory Authentication provider

  • iPlanet Authentication provider

  • Novell Authentication provider

  • Open LDAP Authentication provider

When the Password Validation provider is configured with an authentication provider, the authentication provider invokes the Password Validation provider whenever a password is created or updated. The Password Validation provider then performs a check to determine whether the password meets the criteria established by a set of configurable composition rules.

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 for SAML 1.1

The SAML Identity Assertion provider V2 validates SAML 1.1 assertions and verifies the issuer is trusted. If so, identity is asserted based on the authentication statement 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

SAML 2.0 Identity Assertion Provider

Similar to the SAML Identity Assertion provider V2 for SAML 1.1, the SAML 2.0 Identity Assertion provider validates SAML 2.0 assertions and verifies that the issuer is trusted. If so, identity is asserted based on the authentication statement contained in the assertion.

Provider configuration includes settings that configure and enable SAML 2.0 Service Provider services, such as the Assertion Consumer Service and Artifact Resolution Service, to run in the server.

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

  • 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://docs.oracle.com/javase/7/docs/technotes/guides/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 Oracle 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.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 WebLogic Server 9.1 and later will default to using the XACML Authorization provider. Existing domains, upgraded WebLogic Server 9.1 and later, 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.1 of WebLogic Server also included the "default" WebLogic Authorization provider. This provider supplied the default enforcement of authorization for versions of WebLogic Server prior to 9.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 the WebLogic Adjudication Provider" in Administering Security for Oracle WebLogic Server

WebLogic Role Mapping Provider

As of version 9.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 WebLogic Server 9.1 and later will default to using the XACML Role Mapping provider. Existing domains, upgraded to WebLogic Server 9.1 and later, 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.1 of WebLogic Server also included the "default" WebLogic Role Mapping provider. This provider supplied the default enforcement of role mapping for versions of WebLogic Server prior to WebLogic Server 9.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 for SAML 1.1

The SAML Credential Mapping provider V2 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

SAML 2.0 Credential Mapping Provider

The SAML 2.0 Credential Mapping provider generates SAML 2.0 assertions for authenticated subjects based on the configuration of Identity Provider services and the set of Service Provider partners. 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 for SAML 2.0 include settings that configure and enable SAML 2.0 source site and destination site services (such as Single Sign-On, and Artifact Resolution Service) to run in the server.

The provider supports the following SAML Subject confirmation methods:

  • 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 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 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. Oracle recommends using the WebLogic Keystore provider only when it is needed to support backward compatibility with a WebLogic Server 7.0 configuration.

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.