| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > Introduction to WebLogic Security > The WebLogic Security Service Architecture |
|
Introduction to WebLogic Security
|
The WebLogic Security Service Architecture
The following sections describe the WebLogic Server Security architecture:
An Open Architecture: Multi-Vendor and Multi-Protocol Support
The open, interface-based, security architecture in BEA WebLogic Server allows use of existing security products while taking advantage of new security technologies available in the marketplace. With this architecture, a security installation can support security vendors' full value propositions, not just a subset. A user's choice of security products can be "mixed and matched" to create complete custom security solutions. In fact, a WebLogic Server installation can run more than one security plug-in for a given function, and users can set constraints that govern which product or protocol will be used in a given situation.
As users integrate new solutions or modify existing ones, administrators can set security policy for each security plug-in, using a built-in menu-driven policy tool (see Figure 1-1). Security policy governs authorization: the rules and constraints for accessing resources or assuming roles. More than one security plug-in can run concurrently, as part of a migration or transition scheme, and set security policy accordingly. The BEA-supplied Adjudicator function resolves any conflicts in interpretation when making authorization decisions.
The BEA WebLogic Server design for security services supports any choice of vendors and protocols because it cleanly separates the details of the security system from application code, simplifying application maintenance and management. Changing security system components or policies need not entail modifying applications. This unified architecture makes it easy to integrate best-of-breed security solutions, and to replace components of a security system with the latest technologies from third-party vendors, or from a development staff. The ability to swap in new security plug-ins and technologies, as needed, reduces the total cost of ownership and maximizes the return on investment in security technologies.
Figure 3-1 illustrates the architecture of the WebLogic Security Service.
Figure 3-1 WebLogic Security Service Architecture
Figure 3-1 shows the BEA WebLogic Server Security Service Framework. The primary function of the framework is to provide a simplified application programming interface (API) that can be used by WebLogic Server container developers can to define security services. Within that context, the framework also acts as an intermediary between the WebLogic Server containers and the security provider plug-ins.
The framework consists of the following components:
The WebLogic Server containers call the Principal Authenticator to perform authentication via username and password. For example, a servlet container creates a callback handler to pass down the username and password and then calls authenticate in the Principal Authenticator. The principal authenticator creates a login context and calls login on the login context. The JAAS code calls the configured login modules. A subject is returned from the login context that the Principal authenticator uses it to perform auditing and user lockout functions.
The WebLogic Server containers can also call the Principal Authenticator to perform authentication via a certificate. For example, a servlet container has a certificate from a SSL connection. The container passes down the certificate and a token type of X509 to assertIdentity in the Principal Authenticator and gets back the subject. The principal authenticator finds the provider that has the token type active and gets the identity asserter for that provider. The principal authenticator then calls the provider's identity asserter. The identity asserter returns a callback handler which is used to retrieve the username that should be asserted. The principal authenticator uses the username to create a login context and calls login on the login context. The JAAS code calls the configured login modules. A subject is returned from the login context that the Principal authenticator uses to perform auditing and user lockout functions.
The WebLogic Server containers obtain a reference to the Authorization Manager by calling the Security Service Manager. With that reference the containers use either the isAccessAllowed or isProtectedResource method to call the Authorization Manager. The WebLogic Server containers use the Authorization Manager to determine whether a particular Subject has access to a particular Resource. For example, the container passes in authorization information to the Authorization Manager. The Authorization Manager uses the information to get a reference to the appropriate Authorization Provider that in turn holds a reference to the AccessDecision.
Additionally, the Authorization Manager performs the following functions:
The WebLogic Server containers use the Role Manager and role mapping providers to determine which roles a Subject currently has with respect to a specific protected resource. The role mapping provider returns a role as a form of principal. The WebLogic Server containers obtain a reference to the Role Manager by calling the Security Service Manager. Once they have a reference to the Role Manager, the containers call the RoleMapper.getRoles() method on the role mapping provider. The getRoles() method returns a map of roles indexed by their names, representing the security roles associated with the specified resources that have been granted to the Subject.
WebLogic Server initializes the role mapping providers through the security service framework at boot time. The role mapping providers can also be initialized by an initialize call through the Role Manager or by the Administration Console
The Role Manager also attempts to get a reference to the Auditor. If a reference to an Auditor cannot be obtained, the Role Manager does not perform audits.
When the server boots, during Security Service Manager initialization, if an Audit Provider is configured, the Auditor is instantiated.The Auditor provides a facility to record security events, with their pertinent data and outcomes. Logging of these events provides an audit trail with a purpose of non-repudiation.
The Auditor is called directly by security framework components, such as authentication and authorization to record date, time and event specific data. The Auditor can be called pre- and/or post-operationally. The Default security Audit Provider does not maintain context between pre- and post-operations.
The audit severity levels are as follows:
The Auditor is accessible directly via the security framework; a limited Auditor is accessible to security providers and management runtime MBeans. The Auditor is a back end for the Realm Adaptor Audit facility in Compatibility security. The Auditor fans out Auditor write operations (using the Security Provider Interface) to one or more configured Auditing Providers.
The Credential Manager is used by WebLogic Server containers use to obtain Credential Mapping information. The Credential Manager makes calls through all the configured Credential Mapping providers to get all the relevant information. The Credential Manager is the only component that calls the Credential Mapping providers directly.
The Credential Manager uses the Credential Mapping provider to provide a specific type of credentials. Credential Mapping providers map a user in WebLogic Server to a proper set of credentials to be used to access some external system. For example, a Resource Adapter that plugs into WebLogic Server can provide connectivity between the WebLogic Server and an Enterprise Information System (EIS). To make such connections possible, a Credential Mapping provider is implemented and configured to be used by the Credential Manager to map user credentials that the Resource Adapter can use to access the EIS. For example, the default Credential Mapping Provider that is provided as part of the WebLogic Server product is used to provide username/password credentials, and the provider uses the Embedded LDAP Server to store and manage the mappings.
Custom Credential Mapping providers may be created to provide other types of credentials, such as certificates or keys, for example. Also, a custom Credential Mapping provider could be created to store and manage username/password credentials outside of the WebLogic Server Embedded LDAP 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. If the WebLogic security providers do not fully meet your security requirements, you can supplement or replace them. For more information, see Developing Security Services for WebLogic Server.
The following WebLogic security providers at included in the WebLogic Server product:
WebLogic Authentication Provider
The WebLogic Authentication provider supports delegated username/password and certificate authentication with WebLogic Server, and HTTP certificate authentication through external Web servers. The WebLogic Authentication provider utilizes an embedded LDAP server for the storage of user and group information.
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.
In addition, WebLogic Server provides as set of LDAP Authentication providers which access external LDAP stores (Open LDAP, Netscape iPlanet, Microsoft Active Directory, and Novell NDS).
WebLogic Identity Assertion Provider
Identity Assertion providers allow perimeter authentication. In perimeter authentication, a system outside of WebLogic Server establishes trust via tokens (as opposed to simple authentication whereby WebLogic Server establishes trust via usernames and passwords). An Identity Assertion provider verifies tokens and performs whatever actions are necessary to establish validity and trust in the token.
The WebLogic Identity Assertion provider validates X.509 and IIOP-CSIv2 tokens and maps a token to a WebLogic Server user.
The WebLogic Keystore provider uses the reference Keystore implementation supplied by Sun Microsystems in the Java Development Kit. It utilizes the standard "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:
WebLogic Authorization Provider
The WebLogic Authorization provider supplies the default enforcement of authorization for this version of WebLogic Server. The WebLogic Authorization provider returns an access decision using a policy-based authorization engine to determine if a particular user is allowed access to a protected resource and supports the deployment and undeployment of security policies within the system.
The WebLogic Auditing provider records information about security events, the data associated with a security events, and the outcome to a log file. The logging of security events provides an electronic trail of data that can be used for the purpose of non-repudiation. The WebLogic Auditing provider provides a customizable set of data for auditing security events such as failed login attempts, authentication requests, rejected digital certificates, and invalid roles.
The WebLogic Server Framework can call through to the WebLogic Auditing provider with a request before and after security operations (such as authentication or authorization) have been performed, enabling audit event recording. The decision by the WebLogic Auditing provider to audit a particular event is based on severity levels. During runtime, administrators can use the Administration Console to manage the WebLogic Auditing Provider's severity level.
WebLogic Role Mapping Provider
The WebLogic Role Mapping provider determines dynamic roles for a specific user (Subject) with respect to a specific protected resource. The provider maps roles to users or groups based on policy and determines the appropriate set of roles granted to a WebLogic Server user or group for a WebLogic resource. The role mapping provider returns a role as a form of principal.
Given a reference to the Role Manager, the WebLogic Server containers call the RoleMapper.getRoles() method on the role mapping provider. The getRoles() method returns a map of roles indexed by their names, representing the security roles associated with the specified resources that have been granted to the Subject.
WebLogic Server initializes the role mapping providers through the security service framework at boot time. The role mapping providers can also be initialized by an initialize call through the Role Manager or by the Administration Console
The WebLogic Role Mapping provider supports the deployment and undeployment of roles within the system. Using the Administration Console, administrators can enable or disable role deployment by the WebLogic Role Mapping provider. Role deployment is enabled by default.
The WebLogic Role Mapping provider uses the same policy engine as the WebLogic Authorization provider.
WebLogic Adjudication Provider
The WebLogic Adjudication provider is responsible for adjudicating between potentially differing decisions rendered by multiple Authorization providers. It is used when there are multiple Authorization providers. It adjudicates the results returned from multiple Authorization providers, that is, it examines the results returned and renders a final decision on whether or not access will be granted to a resource.
The default adjudication provider that is provided as part of the WebLogic Server product has an attribute, RequireUnanimousPermit, that governs its behavior. The status of this attribute is displayed on the Administration Console and can be set to true or false. By default, the RequireUnanimousPermit attribute is set to true, which means that all Authorization providers must return a Result of PERMIT in order for the WebLogic Adjudicator provider to return a TRUE verdict. In other words, if any Authorization providers return a verdict of either ABSTAIN or DENY, then the WebLogic Adjudicator provider will return a verdict of FALSE. If RequireUnanimousPermit is false and if all Results are either PERMIT or ABSTAIN, then the WebLogic Adjudicator provider will return TRUE. This means that only if at least one Authorization provider returns a verdict of DENY will the Adjudicator render a verdict of FALSE.
WebLogic Credential Mapping Provider
A Credential Mapping provider supports deploying policies on behalf of Resource Adapter deployment needs. Basically, credential mapping specifies which credential needs to be used by a certain WebLogic Server user when connecting to an Enterprise Information System (EIS) through a Resource Adapter. For example, the EIS may be a mainframe transaction processing, database systems, or legacy applications not written in the Java programming language.
When a Resource Adapter is deployed, credentials and mappings need to be created. Similarly, when the Resource Adapter is redeployed, the credentials and mappings need to be updated. And, when the Resource Adapter is undeployed, the credentials and mappings should be removed. This work is done by a Credential Mapping provider.
The default Credential Mapping provider that ships as part of the WebLogic Server product is used to associate, or map, a WebLogic Server user to the appropriate credentials to be used with a Resource Adapter plug-in to access an EIS system (for example, some relational database like Oracle, SQL Server, and so on.). The provider maps a user's authentication credentials to those required for legacy applications, so that the legacy application gets the necessary credential information. Using the Administration Console, administrators can enable or disable the deployment of the default Credential Mapping provider.
Credential Mappings are specific to a particular component (Resource Adapter) deployed within WebLogic Server. For example, WebLogic Server user "joeuser" may be mapped to the username/password credential "scott/tiger" for Component XYZ, and at the same time be mapped to "sa/admin" for Component ABC.
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. There are four WebLogic Realm Adapter providers:
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.
The Realm Adapter Auditing provider allows you to use implementations of the weblogic.security.audit interface with WebLogic Server deployments using Compatibility security.
The Realm Adapter Adjudication provider is designed to enable both the WebLogic Authorization provider and the Realm Adapter Authorization provider to be used together for a security realm in Compatibility security. In these cases, the WebLogic Authorization provider is used for new, security policies, while the Realm Adapter Authorization provider is used for mapping to 6.1 access control lists (ACLs).
Although these security providers are configured using the WebLogic Server Administration Console, existing 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 WebLogic Server 8.1 security model.
Advantages for Developers, Administrators, and Vendors
Figure 2 illustrates how different types of users would interact with the software architecture of the BEA WebLogic Server security services. The new security architecture has benefits for three categories of users: application developers, third-party security service vendors, and administrators.
Figure 3-2 Types of WebLogic Server Security Users
Administrators who install, configure, deploy and maintain BEA WebLogic Server can use their choice of BEA-supplied security plug-ins, customized security plug-ins, or third-party security products, and manage them all with the Administration Console.
Out of the box, a complete security solution can be implemented using the BEA-supplied security plug-ins. Administrators can use the menu-driven rule-based policy engine to create an authorization scheme that implements your company's business rules.
Benefits for Third-Party Security Service Providers
Most leading security service providers have announced plans to support BEA WebLogic Server 8.1. These providers are integrating their products with the WebLogic Server environment using the Security SPIs. As the underlying integration mechanism for BEA's security plug-ins, the Security SPIs permit development of customized security plug-ins for the WebLogic Server environment. Security SPIs are available for Authentication, Authorization, Auditing, Public Key Infrastructure, Credential Mapping, and Role Mapping. This allows third party vendors to provide tightly integrated solutions that are easy to implement. Reduced development requirements mean an increased return on investment when implementing an enterprise security management solution that includes WebLogic Server. Refer to the BEA Security Center (www.bea.com/products/security/index.shtml) for information on BEA-compliant security vendors.
Benefits for Application Developers
Since most security for Web applications 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. The 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.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
