Security

Digg This!

In some of the typical corporate Web application security deployments, users accessing a protected application are authenticated via enterprise identity/access management products, such as Netegrity's SiteMinder, IBM's WebSEAL, and Oblix's Oblix COREid. The authorization service, however, is delegated to the provider of the application itself, or to the application server.

The application server authorizes a user based on security constraints defined in a Web application's deployment descriptor. However, before the configured security constraints can be applied to provide authorization, the Web containers need to assert that the user is authenticated to begin with. In other words, the front access managers need to provide some information to the back-end Web containers in order to ensure that the Web containers do not attempt to reauthenticate an authenticated user. To accomplish that, it is possible that the front-end access managers may pass the user credentials (username/password) to the back-end servers. This, however, is discouraged for two reasons:

1. In typical deployments, the connectivity between the front-end identity management software and the back-end application servers is not over secured socket layer (SSL), implying that the user credentials would be passed in unencrypted clear text.
2. Even if the connection is made secure, the back-end server will still perform another authentication request for the already authenticated user, using the credentials passed from the front-end access managers, unless it can verify that the request is coming from a trusted source that has already authenticated the user.

This scenario calls for a perimeter authentication, i.e., a user is authenticated only at the front-end access managers. BEA WebLogic Server provides Identity Assertion for achieving identity assertion. This article provides you with a detailed analysis of Identity Assertion implementation in WebLogic Server. You are encouraged to review the product documentation on Identity Assertion providers at http://e-docs.bea.com/wls/docs81/dvspisec/ia.html.

Introduction
From a high-level view, Identity Assertion is implemented by passing tokens from the front-end access managers to the back-end application servers. An Assertion is fundamentally a declaration of one or more facts (statements) about the subject, e.g., a user. A token is primarily a piece of information passed from one system to another that can be used to assert the identity of a particular user. Combined, the tokens and the assertion form the basis for Identity Assertion. In essence, an Identity Assertion provider is a specific form of authentication that allows users or system processes to assert their identities using tokens.

Web Application Security
Before moving to the implementation details in Identity Assertion, let's recap the elements of the Web application security model. The servlet specification provides guidelines for implementing Web application security by the servlet containers. The two forms of security prescribed by the specifications are declarative and programmatic. When the Web application is secured declaratively, the security is configured outside the application via deployment descriptors (web.xml). The authentication method, or the way in which a user is prompted for login, is specified by the <login-config> element in the Web descriptor file, web.xml. If the login-config is present and contains a value other than NONE, the user must be authenticated before he or she can access any resource that is constrained by a <security-constraint>.

When a user tries to access a protected Web resource, the Web container activates the authentication mechanism that has been configured for that resource in the deployment descriptor (web.xml) between <login-config> elements within <auth-method> tags, like this:

<login-config>
  <auth-method>BASIC</auth-method>
</login-config>

The following are the valid authentication methods for Web application security.

• NONE: The user will not be prompted for authentication.
• BASIC: The Web Server will prompt the user for username/password and authenticate against the information provided. In this form of authentication, a user cannot customize the form that collects the username/password.
• FORM: In this case, you can customize the login screen and error pages that are presented to the end user by an HTTP browser.
• CLIENT-CERT: This is a more secure method of authentication than either basic or form based. It uses HTTP over SSL, in which the server and, optionally, the client authenticate one another with Public Key Certificates. Secure Sockets Layer (SSL) provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. As you will see later, it is this form of authentication that WebLogic Server uses to perform Identity Assertion.

When the Web application is secured programmatically, the servlet containers implement certain methods of the HttpServletRequest interface to authenticate/authorize users attempting to access a protected resource. The servlet containers may provide additional methods for programmatic security over and above what is mentioned in the specifications. In WebLogic Server, one such class providing the additional methods is weblogic.servlet.security.ServletAuthentication. ServletAuthentication allows both form-based authentication and programmatic authentication in servlets. It performs the authentication call through the Security Realm and sets the user information for the session. The weak() methods are used for password authentication and the strong() methods are used for certificate-based authentication. Later, we will use methods from this class to allow a Web application user to be authenticated via multiple authentication mechanisms for the same Web application.

Web Application Deployment
Figure 1 represents the frequently used deployment model for Web applications. As depicted in the diagram, when a user attempts to access a protected Web application, the front-end access manager authenticates the users, and routes the authenticated user to the back-end application server. If the Web application has security constraints defined in its deployment descriptor and the roles/attributed are stored in a directory server, the servlet container invokes security APIs to retrieve user/group information from the underlying directory.

Let's walk through the sequence of steps necessary before a valid user can access the protected resource, as presented in the deployment model.

1. User requests a protected Web resource.
2. The front Web server/authenticator server authenticates the user.
3. If the user is authenticated, the request is then forwarded to the back-end application server.
4. However, because the authorization rules/security constraints are configured in the Web application descriptor, the servlet container needs to retrieve the user/group information from the underlying directory store.
5. For the application server to associate the incoming subject with attributes from the underlying store, it needs to ensure that a user is an authenticated user.
6. To enforce the above security requirement, the application server should either reauthenticate the user or assume that the request coming from the front-end access manager is that of an authenticated user.
7. However, making an additional reauthentication call from the application server is not recommended due to its performance overhead. To avoid additional reauthentication calls, the other option for the application server is to assume that the request coming from the front-end access managers is from an authenticated user and bypass the authentication step.

Identity Assertion or perimeter authentication provides a mechanism for the application server to assert that the request coming from the front end is from an authenticated user and thereby avoids reauthentication. This is accomplished by configuring a token that can be passed with the HTTP header request from the front-end access managers to the back-end application server. The following sections explain this in detail.

Token Overview
A token is primarily a secret code passed between the two parties. In essence, a token is the assertion or a statement about a principal as asserted (trusted) by an asserting party. When the receiving party receives a token, it performs a set of operations to validate the incoming token. If the token is validated, it is assumed that the request is coming from a trusted source and no additional authentication is done by the receiving party. In a typical Web environment, the token is passed via HTTP header or via cookie.

In its current implementation, WebLogic Server's default Identity Assertion provider provides support for the following tokens: X.509, CSI.PrincipalName, CSI.ITTAnonymous, and CSI.X509CertChain CSI.DistinguishedName. "Supporting" token types essentially mean that the Identity Assertion provider's runtime class (that is, the IdentityAsserter SSPI implementation) can validate the token type in its assertIdentity method.

Since the above tokens may not meet the need for all the applications, you can easily create a new, custom token for your environment. Creating a custom token requires writing a custom Identity Assertion provider that implements the IdentityAsserter Security Service Provider Interface (SSPI). SSPI in WebLogic Server provides a way to develop custom security providers. The custom token type can be as simple as a piece of string. For example, the following piece of code defined in the Custom Identity Assertion Provider Implementation defines a new token type.

public final static String MY_TOKEN_TYPE = "MyCustomIAToken";

After a new token type is defined, it can be configured via WebLogic Console as described in the BEA product documentation. Once configured and active, these tokens can then be used by the WebLogic Security framework to assert the identity of the incoming requests.

Sequence Flow
Figure 2 represents the sequence of steps that happen during Identity Assertion process:

1. During the deployment of the Web application, the Web container identifies that the Web application's authentication method is configured as CLIENT-CERT.
2. The Web container creates and initializes a corresponding SecurityModule - in this case it creates CertSecurityModule.
3. When the Web resource is accessed by the client, the server's ServletSecurityManager invokes the CertSecurityModule to check the user permissions to access the resource.
4. The CertSecurityModule then invokes the server's security module to find any tokens present in the request object. CertSecurityModule looks for tokens in the HTTP header or in the cookie that were configured during the Identity Assertion configuration. In essence, it iterates through the header values and attempts to match header values with predefined tokens from the WebLogic console.
5. If there is any valid token present in the request, the SecurityModule then attempts to assert the identity of the user.
6. At this time, the server's security module passes the control to the custom Identity Assertion provider implementation.
7. Custom Identity Assertion provider verifies the validity of the token and extracts the username from it.
8. The custom Identity Assertion provider generates JAAS CallBackHandler. Java Authentication and Authorization Service (JAAS) is a set of APIs that enable services to authenticate and enforce access controls upon users. Refer to http://java.sun.com/products/jaas/ for more details on JAAS.
9. The CallBackHandler verifies that the list of callbacks contains a name call back (else it throws an exception) and appropriately sets the username.
10. The NameCallBack ensures that the user is present in the underlying security realms and grants access to the user based on the defined rules.

Relationship with JAAS
It is important to note that the Identity Assertion does not fall under the JAAS umbrella - i.e., JAAS does not provide any specific guidelines on implementing Identity Assertion. The only correlation between the Identity Assertion and JAAS is that Identity Assertion's implementation returns a javax.security.auth.callback.CallbackHandler (http://java.sun.com/j2se/1.4.2/docs/api/javax/security/ auth/callback/CallbackHandler.html). As you may recall, when a JAAS LoginModule needs to communicate with the user - for example, ask the user for a username and password - it does so by invoking a CallBackHandler. The CallBackHandler's handle() method then generates the appropriate CallBack to obtain the requested information. In case of Identity Assertion, the custom security provider verifies that the token passed in the request is valid, and subsequently generates a NameCallBack alone.

Multiple Authentication Mechanism
Earlier in this article, we reviewed the Web application security model. One problem with specifying the authentication method in the login-config is that, at a given time, only one authentication method can be configured for one Web application. In certain cases, however, there is a need to serve users from multiple sources, i.e., the users coming from a trusted source (front-end access managers) containing the defined tokens and the users not coming from the trusted source. This may include users from within the internal network who can access the application server directly. In other words, depending on where the request is coming from, the servlet security implementation may need to generate two different CallBackHandlers. However, there is no provision in the servlet specification that allows for multiple authentication methods. This calls for a programmatic solution that may be specific to Web container providers. As I indicated earlier, WebLogic provides weblogic.servlet.security.ServletAuthentication for programmatic authentication from within Web applications. The ServletAuthentication method provides two important methods for authentication:

• weak(): Returns an int value for AUTHENTICATED or FAILED_AUTHENTICATION after pulling the username and password from the request, authenticating the user, and setting it into the session
• strong(): Strong authentication uses the client-side certificate chain as the credential for authentication against the "WebLogic" (default) realm.

Figure 3 provides the sequence of steps in this configuration. In cases of Identity Assertion, the servlet container invokes ServletAuthentication's strong() method. To accomplish multiple authentication methods (CLIENT-CERT and FORM-based) for the same Web application, the option includes invoking the methods programmatically in the login form. In other words, the login form performs a strong authentication (client-cert) first. If a valid token is present in the request header or in the cookie, the user is given access to the resource. If the strong authentication fails, the user is then prompted for a username and password via the login form. Note that because the BASIC form of authentication does not provide a capability to customize the authentication form and provide any programming capabilities in the form, a programmatic combination of BASIC and CLIENT-CERT authentication methods is not possible.

Alternative Solutions
Identity Assertion is not the only possible solution for this problem. Some of the other solutions include passing a shared secret (or a token) between the two parties. In this case, both the sender and the receiver agree upon a shared secret before hand. If any requests arrive with the correct value of the shared secret, the receiving party can trust that the request is coming from a trusted source and allows access to the underlying resource.

Other solutions, such as IP-based trust, can be used for this as well. In this case, the application checks whether or not the request is coming from a preconfigured, trusted IP address before the request is granted access. This typically would be the IP of the Web server in the DMZ.

Conclusion
This article offered details on how BEA WebLogic Server provides a mechanism to perform perimeter authentication via Identity Assertion. This method is useful in situations when the front-end access managers perform the authentication and multiple back-end servers trust that the requests coming from them are authenticated and therefore do not need additional authentication.

References

WebLogic Security Documentation: http://e-docs.bea.com/wls/docs81/dvspisec/ia.html

Sample Custom Security Providers: http://dev2dev.bea.com/codelibrary/code/security_prov81.jsp

Java Authentication and Authorization Service (JAAS): http://java.sun.com/products/jaas/

Servlet Specifications: http://jcp.org/aboutjava/communityprocess/finaljsr154/index.html