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

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.

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

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.

 

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

  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:

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

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

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 step 6 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 Unauthorized
    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:

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.

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

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:

For more information, see Developing security providers for 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

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.

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:

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:

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:

 

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:

 

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:

 

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

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

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 you change the Require Unanimous Permit attribute to FALSE, the WebLogic Adjudication provider acts as follows:

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

 

SAML 2.0 credential mapping Provider f

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:

 

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:

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

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.

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.