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

To secure WebLogic applications running inside of the WebLogic Server container environment, the WebLogic Server security framework set out to accomplish the following goals:

• Security as a service— Security is now viewed as a service available to application components. Application components call upon WebLogic Server security for features such as authentication and authorization. Due to its modular nature, WebLogic Server allows third-party software vendors to integrate their security solutions seamlessly. The configuration of this software is from the same administrator console used for configuring other aspects of WebLogic Server. As new security technologies become available, existing applications can take advantage of them. For example, if authorization by fingerprinting is used in the future, WebLogic Server can utilize a third-party software vendor's authorization module. Then application code will utilize this module with little or no changes to the application code.

• Separation between security code and application code— Developers are encouraged and have more reasons to not put security-related code inside of application code. One reason for this is that WebLogic Server security policies allow decisions concerning security to be based on business logic, reducing the need for security-related code. Keeping this separation is important because it allows the security features of an application to change independent of application code changes.

• Ship more functionality out of the box— In the past, developers were responsible for implementing some security-related with code. WebLogic Server now supplies more security functionality out of the box. For instance, auditing is now a feature of WebLogic Server, configurable from the Administrator Console.

• Unified security model— With WebLogic Server 8.1, all security configurations can be set from the Administrator Console. In the past, security was configured in many different ways.

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.

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.

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.

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

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.

Security Providers

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

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.

Authorizers

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.

Adjudicators

When configuring an application with complex security policies, it is possible that multiple security policies could be in place to protect a restricted resource.

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.

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

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

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.

Table 27.1. WebLogic Auditing Provider Events

Audit Event	Description
AUTHENTICATE	Username/password authentication occurred
ASSERTIDENTITY	Perimeter (token-based) authentication occurred
USERLOCKED	User account locked for too many invalid login attempts
USERUNLOCKED	User account has been cleared
USERLOCKOUTEXPIRED	User account lock has expired

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.

Table 27.2. Security Provider Rules

Security Provider	Required?	Multiple Allowed?
Authentication	Yes	Yes
Identity Assertion	No	Yes
Principal Validation	Yes	Yes
Authorization	Yes	Yes
Adjudication	Yes (only if there are multiple authorization providers)	No
Role Mapping	Yes	Yes
Auditing	No	Yes
Credential Mapping	No	Yes