WebLogic Security Service Architecture

This section covers the following topics:

 

Architectural Overview

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 4-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 4-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 4-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 4-2 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 4-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 4-3), a token from outside of the WebLogic Server domain is passed to an Identity Assertion provider in a security realm that is responsible for validating tokens of that type and that is configured as "active." If the token is successfully validated, the Identity Assertion provider maps the token to a WebLogic Server username, and sends that username back to WebLogic Server, which then continues the authentication process. Specifically, the username is sent via a JAAS CallbackHandler and passed to each configured Authentication provider's LoginModule, so that the LoginModule can populate the subject with the appropriate principals.

Note: To use the WebLogic Identity Assertion provider for X.501 and X.509 certificates, you have the option of using the default user name mapper that is supplied with the WebLogic Server product (weblogic.security.providers.authentication. DefaultUserNameMapperImpl) or providing you own implementation of the weblogic.security.providers.authentication.UserNameMapper interface. For more information, see Do I Need to Develop a Custom Identity Assertion Provider? in Developing Security Providers for WebLogic Server.

Figure 4-3 Perimeter Authentication


As Figure 4-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 4-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 4-4 The Principal Validation Process


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

 

The Authorization Process

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

Figure 4-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 4-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 4-6 shows how the Role Mapping providers interact with the WebLogic Security Framework to create dynamic role associations.

Figure 4-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 2 Enterprise Edition (J2EE) isCallerInRole method to retrieve fields from a record in a database, without having knowledge of the business policies that determine whether access is allowed.

 

The Auditing Process

Figure 4-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 4-7 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 4-8 illustrates how Credential Mapping providers interact with the WebLogic Security Framework during the credential mapping process.

Figure 4-8 Credential Mapping Process


The credential mapping process is initiated when application components, such as JavaServer Pages , servlets, Enterprise JavaBeans , 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 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, and Role Mapping. Note that 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 Managing WebLogic Server.

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

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

 

The WebLogic Security Providers

This section provides descriptions of the WebLogic 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 WebLogic security providers supplied with the WebLogic Server product do not fully meet your security requirements, you can supplement or replace them with custom security providers. You develop a custom security provider by:

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

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

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

Figure 4-9 WebLogic Security Providers


The WebLogic security providers are described in the following sections:

 

WebLogic Authentication Provider

The default (active) security realm for WebLogic Server includes a WebLogic Authentication provider.

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.

The WebLogic Authentication provider supports delegated username/password authentication, and 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 addition, WebLogic Server provides a set of LDAP Authentication providers that access external LDAP stores (Open LDAP, Netscape iPlanet, Microsoft Active Directory, and Novell NDS).

Note: By default, the LDAP Authentication providers are not configured in the WebLogic default security realm.

 

WebLogic Identity Assertion Provider

The WebLogic Identity Assertion provider supports certificate authentication using X.509 certificates and CORBA Common Secure Interoperability version 2 (CSIv2) identity assertion.

The WebLogic Identity Assertion provider validates the token type, then maps X.509 digital certificates and X.501 distinguished names to WebLogic usernames. 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.

 

WebLogic Principal Validation Provider

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

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

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

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

 

WebLogic Authorization Provider

The default (active) security realm for WebLogic Server includes a WebLogic Authorization provider. This provider supplies the default enforcement of authorization for this version of WebLogic Server. 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 that the WebLogic Adjudication provider is used in the Compatibility realm, which has two Authorization providers.

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

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

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

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

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

 

WebLogic Role Mapping Provider

The default (active) security realm for WebLogic Server includes a WebLogic Role Mapping provider. 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. 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.

 

WebLogic Keystore Provider

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

  • One keystore file holds the trusted certificate authority (CA) certificates. WebLogic Server also ships a trusted certificate authority Keystore file that it uses by default to locate the trusted CA certificates, which are then used in SSL to verify client certificates.
  • The other keystore file holds the server's private keys. WebLogic Server retrieves a private key from this file to initialize SSL. You can use the Sun Microsystems SDK keytool utility or the WebLogic Server ImportPrivateKey utility to add private keys to this file. Note that WebLogic Server can retrieve private keys and certificates from this keystore file.
Note that the WebLogic Keystore provider is deprecated in this release of WebLogic Server but is still supported. The development of custom Keystore providers is not supported. Use Java KeyStores (JKS) instead. All of the functionality that was supported by the WebLogic Keystore provider is available through use of Java KeyStores. The WebLogic Keystore provider is only supported for backward compatibility. BEA recommends using the WebLogic Keystore provider only when it is needed to support backward compatibility with a WebLogic Server 7.0 configuration. For information on how to use Java KeyStores, see Configuring Keystores in Managing WebLogic Server.

 

WebLogic Realm Adapter Providers

The WebLogic Realm Adapter providers provide backward-compatibility with 6.x WebLogic security realms by allowing the use of existing, 6.x security realms with the security features in this release of WebLogic Server. The WebLogic Realm Adapter providers map the realm API (weblogic.security.acl) used in WebLogic Server 6.x to the APIs used in this release of WebLogic Server. The following WebLogic Realm Adapter providers are provided:

  • Authentication (includes an Identity Assertion provider)

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

  • Authorization

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

  • Auditing

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

  • Adjudication

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

Although these security providers are configured using the WebLogic Server Administration Console, your existing 6.x security realms will continue to use the same MBeans and user interface present in WebLogic Server 6.1. Note that the WebLogic Realm Adapter providers are deprecated and should only be used while upgrading to the WebLogic Server 8.1 security model.

 

How the Architecture Benefits Users

The WebLogic security service architecture provides specific benefits for the following categories of users:

 

Application Developers

Since most security for Web applications and EJBs can be implemented by a system administrator, application developers need not pay attention to the details of securing the application, unless there are special considerations that must be addressed in the code. For programming custom security into an application, WebLogic Server application developers can take advantage of BEA-supplied Application Programming Interfaces (APIs) for obtaining information about subjects and principals (identifying information for users) that are used by WebLogic Server. These APIs are found in the weblogic.security package.

With WebLogic Server's comprehensive support for the Java standards, developers of applications for WebLogic Server can also use the APIs in the Java platform security packages such as JAAS and JSSE, as well as the security-specific methods defined by J2EE.

 

Server/Application Administrators

Out of the box, administrators can use WebLogic Sever security providers to implement a complete security solution. Administrators can use the Administration Console to define security roles and assign security policies to WebLogic resources so as to create an authorization scheme that implements your company's business rules.

 

Third-Party Security Service Providers

Most industry leading, security service providers have announced plans to support BEA WebLogic Server 8.1. These third-party providers are integrating their products with the WebLogic Server environment using the Security Service Provider Interfaces (SSPIs). As the underlying integration mechanism for WebLogic security providers, the SSPIs allow development of customized security providers for the WebLogic Server environment. SSPIs are available for Adjudication, Auditing, Authentication, Authorization, Credential Mapping, Identity Assertion, and Role Mapping. Note that 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 Managing WebLogic Server.

This architecture allows security developers to provide tightly integrated solutions that are easy to implement. The result is a reduction in development requirements, which means an increased return on investment when implementing an enterprise security management solution.

For information on BEA-compliant security vendors, see the BEA Security Center at http://www.bea.com/framework.jsp?CNT=isv.htm&FP=/content/partners/strategic/.

Skip navigation bar  Back to Top Previous Next