|[ Team LiB ]|
How Security Works in WebLogic Server
The security model in WebLogic Server 8.1 has changed considerably from previous versions. As in other areas of the J2EE specification, WebLogic Server meets the security requirements of J2EE and then extends them in many directions to offer developers and administrators many additional features to make their jobs easier. The J2EE security specification does not specify any security-specific tools or user interfaces from compliant application servers. In fact, this is a key area for differentiation and WebLogic Server has taken full advantage of it. As illustrated in Figure 27.14, WebLogic Server security builds on security offered through J2SE and J2EE (including JAAS).
The WebLogic Server security model is based on a modular design that exposes a set of Security Service Provider Interfaces (SSPIs) for authentication, authorization, auditing, and other security features. This allows third-party vendors to create security software that will seamlessly integrate with WebLogic Server. By integrating with WebLogic Server, third-party software is configurable from the WebLogic Server administration console.
Goals of WebLogic Server Security Framework
Java Authentication and Authorization Service
While the J2SE security model has been specific about how security should be implemented, the J2EE specification has left many aspects ambiguous. This has caused application server vendors to implement security models that are extremely proprietary, thus compromising one of Java's key principals of write once, run anywhere. The Java Authentication and Authorization Service (JAAS) specification puts a stake in the ground and gives application server vendors more direction on how to implement security. This spec comes with a set of classes and interfaces for authenticating users based on flexible credentials and for authorizing users access to restricted resources. JAAS version 1.0 is an optional package of the Java 2 SDK version 1.3.x, but it is a standard package in version 1.4.
JAAS implements a Java version of the Pluggable Authentication Model (PAM) framework. Originally developed in the Unix world, PAM allows for a flexible authentication and authorization system that can evolve separately from the rest of a security framework and from applications that rely on this framework. As new authentication technologies such as biometrics, Kerberos ticketing, and smart cards become available, security providers can provide software that connects their new hardware to JAAS.
The JAAS API defines a LoginModule abstraction that connects authentication hardware and software to the rest of the IT infrastructure. This is similar to the concept of using hardware drivers to connect computer hardware to an operating system. The JAAS API also defines a LoginContext abstraction that calls on one or more LoginModule abstractions to authenticate a user, as illustrated in Figure 27.15.
Figure 27.15. WebLogic Server uses JAAS for a flexible authentication model. Out-of-the-box and customized LoginModule abstractions are used to connect the WebLogic Server security framework to different data sources and security mechanisms for authentication purposes.
WebLogic Server implements the JAAS version 1.0 specification and uses it for authentication purposes only. The JAAS specification for authorization states that a policy file should be used to indicate who is allowed access to restricted resources. However, WebLogic Server uses security realms and roles to determine user access. Your need to learn JAAS at the API level is based on your security requirements. Out of the box, WebLogic Server ships with JAAS authentication modules to handle username/password combinations, digital certificates, and many external LDAP servers. If your applications require additional methods of authentication, you'll either need to obtain custom LoginModule implementations or write your own. In the next chapter, we'll discuss JAAS development.
Subjects and Principals
JAAS defines new terms for dealing with authentication. The definition of the term principal is an identity assigned to an authenticated user of an application or computing resource such as a socket or a file. The definition of the term subject is a container for authentication information including a set of principals. In the JAAS API, there are classes to represent subjects and principals.
When a client is being authenticated, a LoginContext will create a new Subject object. The LoginContext then passes the empty Subject object to one or more LoginModule objects. As each LoginModule authenticates the client using its own respective method, they will create Principal objects. The LoginModule objects will then populate the Subject object with these Principal objects. For example, a single authenticating user may invoke multiple LoginModule objects that generate principals based on the user's name and their Social Security number.
After a client has been authenticated, the client application will receive a Subject object filled with associated Principal objects. When the client application attempts to perform restricted operations on a remote system, it will pass its Subject object with the request. The remote system, in our case WebLogic Server, will determine whether any of the embedded principals have the correct access rights to perform this task.
WebLogic Server Security Realms
At the top of the WebLogic Server security model hierarchy is the security realm. As depicted in Figure 27.16, a security realm integrates all information associated with security, including users, groups, authenticators, and authorization information. A realm includes a set of security providers that each performs specific security-related functions. Every WebLogic Server domain must have at least one active security realm. There can be multiple realms, but only one can be active at a time.
Figure 27.16. Realms provide an integrated structure to all the security information and functionality within an application.
WebLogic Server is configured out of the box with a default realm called myrealm. This can be seen in the Administration Console as shown in Figure 27.17. Inside of this realm, WebLogic Server ships with its own default implementations of each of these security providers. If your security needs are not met by the WebLogic Server implementations, you are free to purchase other implementations from third-party vendors or to write your own. A single security realm can integrate security providers that come with WebLogic Server, are created for custom purposes, and are purchased from third-party security software vendors.
Figure 27.17. The default security realm called myrealm contains WebLogic Server–supplied security providers.
Every WebLogic Server domain must have at least one security realm with which it is associated. If a domain is created and it is associated with the myrealm realm and then this realm is removed, you will not be able to start WebLogic Server in this domain.
Security roles are used to group together users that share access rights to restricted resources. Security roles are similar to groups in the sense that they are both collections of users. However, whereas the membership of a group is fairly static and modifiable only by an administrator, rules are used to define the membership of a role. This makes the membership of roles dynamic. WebLogic Server enhances static security roles represented in J2EE deployment descriptors with dynamic ones set through the Administrator Console. Security roles replace the access control lists (ACLs) used in previous versions of WebLogic Server.
The WebLogic Server security framework enhances J2EE security and enables most resources to be protected. These include resources from the JDBC, JNDI, JMS, EJB, Web application, and administration subsystems.
As mentioned earlier, a single security realm within WebLogic Server consists of security providers that are each assigned a specific set of responsibilities in regard to maintaining the security of Web applications. In this section, we discuss each type of security provider and what it is responsible for.
Authentication providers are responsible for taking client credentials and matching them with a registered WebLogic Server user. These credentials can come in many shapes and sizes. Examples include username and password, digital certificates, and fingerprints.
Authentication providers are responsible for invoking JAAS LoginModule objects that will determine valid Principal objects based on supplied client authentication credentials. The authentication provider will return a populated JAAS Subject object back to a remote client after a successful login. Because remote clients hold and can possible modify Subject objects, principal validators are used to ensure that the embedded Principal objects have not been tampered with. The WebLogic principal validation provider signs and validates WebLogic Server principals, users, and groups. If you need to work with principals from another application, such as SAP, you might need to create a custom principal validator.
When remote clients attempt to authenticate with WebLogic Server using a token, it is referred to as perimeter authorization. These tokens are client credentials such as digital certificates. Identity asserters are responsible for accepting tokens that are generated outside of WebLogic Server and associating them with a WebLogic Server username. Then they pass the token back to WebLogic Server where they are authenticated. Although identity asserters can handle many types of tokens, they can handle only one at a time, and the type that is configured as active. To handle multiple types of tokens, there must be multiple identity asserters.
The WebLogic authentication provider (named DefaultAuthenticator) uses an embedded LDAP server to store user and group information. The provider authenticates users by matching their usernames and passwords with the information in the embedded LDAP server. This provider allows for a configurable minimum password length with default of 8.
The WebLogic identity assertion provider (named DefaultIdentityAsserter) can accept tokens for X.509 digital certificates and Common Secure Interoperability (CSIv2) identities. CSIv2 is a standard for securing operations made over RMI-IIOP. If you need to handle other types of tokens, such as Kerberos or SAML, you will need to create or purchase a custom IdentityAsserter.
Authorization providers are responsible for determining when an authenticated user has access to a restricted resource. This is performed at runtime by comparing security policies with the identity of the authenticated user. When asked whether a user can access a restricted resource, an authorizer can vote PERMIT, DENY, or ABSTAIN. The adjudicator will use this information to make a final decision on access.
The WebLogic Server authorization provider (named DefaultAuthorizer) can read in security policies declared in deployment descriptors. After these policies are stored in WebLogic Server, they can be modified from the Administration Console. However, these changes are not written back to the original deployment descriptor. They are, however, stored in the embedded LDAP server. The consequence of this is that if the application component is deployed again, the security policy in the deployment descriptor will overwrite information in the LDAP server.
Imagine a bank where an Account EJB with a deposit method is marked as restricted. A security policy with one authorization provider is set up based on the time of the day. It must be between 9 a.m. and 6 p.m. for the deposit method to be available. Another security policy set up with a different authorization provider is also set for this method based on the CanDeposit role. Let's say that both bank tellers and managers are included in this role. When a bank teller tries to make a deposit at 6:02 p.m. because the bank had to stay open for a very wealthy client, should access be allowed? This scenario is illustrated in Figure 27.18. The job of an adjudicator is to decide whether to give access to a restricted resource when different authorization providers return different access rights.
Figure 27.18. Adjudicators get the final say when authorizers can't agree on whether to grant access.
The WebLogic Server–supplied adjudicator provider (named DefaultAdjudicator) provides a very simple mechanism to make this decision. If the RequireUnanimousPermit attribute is set, all authorization providers must respond with a PERMIT vote in order to allow the user access. If the attribute is disabled, ABSTAIN votes will be ignored. If you are using multiple authorizers and you need a more complex decision-making process to decide on access, you will need to develop or purchase a custom adjudicator.
Keystore providers allow the private keys of users to be stored in a password-protected database. This provides an extra level of protection for this sensitive information. Applications that use SSL with keys and certificates must use have a default realm with a defined keystore provider.
The WebLogic Server keystore provider stores keys and certificates generated with the J2SE keytool. This provider stores both users' private keys and trusted CA certificates. The keytool utility or the WebLogic Server ImportPrivateKey utility can be used to add private keys to this providers' private key file.
Role Mapping Providers
Role mapping providers allow the WebLogic Server security framework to use complex business logic that determines at runtime if a user is in a particular role. The WebLogic Server security framework allows roles to be created based on rules concerning username, group membership, and time of day. The business logic contained in a role mapping provider can use rules that are much more complex and are application specific. Role mapping providers give role information to authorizers to help them determine whether a user should have access to a restricted resource.
The WebLogic Server role mapping provider (named DefaultRoleMapper) contains an attribute named RoleDeploymentEnabled. When set, this provider will use roles that have been set in Web application and EJB deployment descriptors (in weblogic.xml and weblogic-ejb-jar.xml files). This provider uses the roles in deployment descriptors and WebLogic Server security roles set in the Administrator Console. If your organization already has a role mapping implementation in place, you need to create a custom role mapping provider that will utilize that system.
Credential Mapping Provider
Credential mapping providers provides a means of determining credential information to authenticate a user on an external systems based on whomever is the current user. These external systems include databases and EIS instances.
The WebLogic Server credential mapping provider (named DefaultCredentialMapper) contains an attribute named CredentialMappingDeploymentEnabled. When set, this provider will read credential mapping information from deployment descriptors (in weblogic-ra.xml) in resource adapters when they are deployed. This provider maps WebLogic Server users and groups to usernames and passwords in external systems. If you want to map to other credentials, such as Kerberos tickets, you will need a custom credential mapping provider.
Auditing providers provide a way to collect, store, and distribute information supplied by other security providers (most notably, authentication and authorization providers). If they have been configured to do so, other security providers will pass auditing providers AuditEvent objects representing actions auditing such as login and logout. Auditing providers will then read the information in these AuditEvent objects and store them in their own designated mechanisms, examples of which are LDAP and RDBMS. Typical auditing events are authentication on name and password or tokens, and user account locking and unlocking. Auditing providers store this information for the purposes of nonrepudiation.
The WebLogic auditing provider stores audit information in a file named DefaultAuditRecorder.log located in your WebLogic application domain's root directory (for example, [WEBLOGIC_HOME]\user_projects\domains\mydomain). This provider stores the audit events in Table 27.1. This provider can store events based on its current severity level. These levels are NONE, INFORMATION, WARNING, ERROR, SUCCESS and FAILURE. If you want to output to another file or another medium, such as a database, you will need a custom auditing provider.
Rules About Security Providers and Realms
Due to the way security providers work with the WebLogic Server security framework, there are rules concerning which providers are required and which can occur more than once in a security realm. These are described in Table 27.2.
|[ Team LiB ]|