WebLogic Server's identity assertion--reprint

In some typical corporate Web application security deployments, users who access protected applications are managed through Enterprise identity/access management products such as netegrity siteminder,ibm webseal and Oblix Oblix Coreid. However, the authentication service is delegated to the provider or application server of the application itself.

The application server authorizes the user based on the security constraints defined in the Web application deployment profile. However, before the configured security constraints are used to provide authentication, the Web container needs to determine that the user is authenticated before it can begin to work. In other words, the front-end access Manager needs to provide some information to the backend Web container to ensure that the Web container does not attempt to re-authenticate authenticated users. To achieve this, the front-end access Manager may need to hand over the user credentials (username/password) to the backend server. However, this can be thwarted by the following two reasons:

• In a typical deployment, the connection between the front-end identity management software and the back-end application server does not pass through Secure Sockets Layer (SSL), which means that the user certificate is passed as non-encrypted plain text.
• Even if the connection is secure, the backend server will use the certificate from the front-end access Manager to authenticate the authenticated user again unless it can verify that the request came from a trusted source, the authenticated user.

This situation requires perimeter authentication, which means that the user is authenticated only in the front-end access Manager. BEA WebLogic Server provides an identity assertion for implementing identity assertions. This article gives you a detailed analysis of the implementation of the identity assertion in WebLogic Server . We recommend that you first review the product documentation for the identity assertion provider in http://e-docs.bea.com/wls/docs81/dvspisec/ia.html.

Brief introduction

From a high-level perspective, Identity assertion is implemented by passing tokens from the front-end access Manager back-end application server. Essentially, assertions are statements of facts (statements) about a subject (such as a user). Tokens are a piece of information that is passed from one system to another and can be used to identify a particular user. The combination of tokens and assertions constitutes the basis of the identity assertion. Essentially, the identity assertion provider is a special form of authentication that enables a user or system process to use tokens for identity assertion.

Web Application Security

before introducing the implementation details of the identity assertion, let's briefly explain how the Web application security model works. The servlet specification provides guidelines for implementing Web application Security through a servlet container. The two forms of security specified by the specification are declarative and procedural in nature. When Web application security is declarative, security is configured outside the application through the deployment character (XML). The authentication method, or the method that prompts the user to log on, is specified by the <login-config> element in Web descriptor file, XML. If the login configuration appears and contains a nonzero value, the user must authenticate before accessing any <security-constraint> constrained resources.

When a user tries to access a protected Web resource, the Web container activates the authentication mechanism, which is configured for the resources in the deployment description file (Web. xml), which is located inside the <login-config> element < Auth-method> tags, just like this:

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

The following are valid authentication methods for implementing Web Application Security:

• NONE : The user is not prompted for authentication.
• BASIC : The Web server prompts the user to enter a user name/password and authenticates the information provided. In this authentication method, the user cannot customize the form that collects the user name/password.
• FORM : In this case, you can customize the login screen and error page displayed to the end user through an HTTP browser.
• Client-cert : This is a more secure authentication method than the base method or form method. It uses the server's SSL and HTTP, or the client authentication with public key certificates. Secure Sockets Layer (SSL) provides weblogic Server   is exactly what it is that uses this form of authentication to perform identity assertions.

When Web application security is procedural, the servlet container can implement some HttpServletRequest interface methods for authentication/authorization attempts to access the protected resource's users. Servlet containers provide additional methods for procedural security that are not mentioned in the specification. In WebLogic Server , the class that provides the extra method is weblogic.servlet.security.ServletAuthentication. Servletauthentication allows forms-based authentication and procedural authentication in the servlet. It performs authentication calls through the security Realm and sets user information for the session. The weak () method is used for password authentication and strong () is used for certificate-based authentication. Later we will use methods from this class to allow authentication of Web application users through the multi-factor authentication mechanism of the same Web application.

Web Application Deployment

Figure 1 represents a common deployment model for WEB applications. , when a user tries to access a protected Web application, the front-end access Manager authenticates those users and routes the authenticated user to the backend application server. If the Web application defines security constraints in the deployment profile and the roles/attributes are stored on the directory server, the servlet container invokes the security API to obtain user/group information from the underlying directory.

Figure 1 WEB Application Deployment

Let's take a look at the steps that a valid user must go through to access a protected resource, as shown in the deployment model.

• The user requests a protected web resource.
• The front-end Web server/authentication server authenticates the user.
• If the user passes authentication, the request is passed to the backend application server.
• However, because authentication rules/Security constraints are configured in the Web application description file, the servlet container needs to obtain user/group information from the underlying directory storage.
• The application server needs to ensure that the user is authenticated in order to correlate the incoming topic with the properties of the underlying storage.
• To perform the above security requirements, the application server should re-authenticate the user, or assume that the request from the front-end access Manager is issued by an authenticated user.
• However, additional reauthentication from the application server is not recommended as this requires additional overhead. To avoid additional reauthentication calls, another option for the application server is to bypass the authentication step by assuming that requests from the front-end access Manager come from authenticated users.

Identity assertion or perimeter authentication provides a mechanism for application servers to assert that front-end requests are from authenticated users, thereby avoiding reauthentication. This is accomplished by configuring tokens that can be passed from the front-end access Manager to the backend application server along with the HTTP header request. This is explained in detail in the next section.

Token Overview

Tokens are primarily secret codes passed between two parties. Essentially, a token is an assertion or declaration about a subject that is perceived by the asserted party as declarative (trustworthy). When the receiving party receives the token, it does a set of actions to validate the incoming token. If the token is validated, the request is assumed to be from a trusted resource, and the receiver does not perform additional authentication. In a typical web environment, tokens are passed through an HTTP header or cookie.

In the current implementation, the default identity assertion provider forWebLogic Server supports the following tokens: +/CSI. PrincipalName, CSI. Ittanonymous and Csi.x509certchain CSI. DistinguishedName. The "Support" token type essentially means that the runtime class of the identity assertion provider (that is, the identityasserter SSPI implementation) can use the Assertidentity method to validate the token type.

Because these tokens may not meet the needs of all applications, you can easily create new custom tokens for your environment. Building a custom token requires writing a custom identity assertion provider that implements the Identityasserter Security Service Provider Interface (SSPI). The SSPI of WebLogic Server provides a way to develop a custom security provider. A custom token type can be as simple as a string. For example, defining the following code snippet in custom Identity assertion Provider implementation defines a new token type.

Public final static String My_token_type = "Mycustomiatoken";

Once a new token type has been defined, it can be configured as WebLogic Console as described in the BEA product documentation. Once the configuration is complete and activated, these tokens can be used by the WebLogic Security schema to assert the identity of the incoming request.

Sequence diagram

Figure 2 shows the sequence of steps to perform the identity assertion period:

Figure 2 Identity Assertion sequence

1. During Web application deployment, the Web container first determines that the authentication method for the Web application is configured as Client-cert.
2. The Web container creates and initializes the corresponding securitymodule in this example, it creates the certsecuritymodule.
3. When a client accesses a Web resource, the server's Servletsecuritymanager calls Certsecuritymodule to check the user's permissions to access the resource.
4. Then Certsecuritymodule calls the server's security module and looks for all tokens in the requested object. Certsecuritymodule looks for tokens configured in the HTTP header or cookie during identity assertion configuration. Essentially, it iterates over the head value and tries to match the header value to the predefined token in the WebLogic console.
5. If a valid token appears in the request, Securitymodule attempts to assert the user's identity.
6. At this point, the server's security module passes control to the custom identity assertion provider implementation.
7. The custom Identity Assertion Validator verifies the validity of the token and extracts the user name from it.
8. The custom identity assertion provider generates a Jaas CallbackHandler. Java Authentication and Authorization service (JAAS) is a set of APIs that enable the authentication service and perform user access control. For more details on Jaas, please refer to http://java.sun.com/products/jaas/.
9. CallbackHandler validates a callback manifest that contains a callback name (otherwise it throws an exception) and sets the user name appropriately.
10. NameCallback ensures that users appear in the underlying security realm and that user access is authorized based on defined rules.

The relationship to Jaas

It is important to note that the identity assertion is not protected by Jaas, which means that Jaas does not provide any specific guidance for implementing the identity assertion. The only association between assertion and Jaas is that the implementation of the identity assertion returns a Javax.security.auth.callback.CallbackHandler (http://java.sun.com/ j2se/1.4.2/docs/api/javax/security/auth/callback/callbackhandler.html). You may recall that when JAAS Loginmodule needs to communicate with the user (for example, requiring the user to enter a user name and password), it is implemented by calling CallbackHandler. The CallbackHandler () method then generates the appropriate CallBack to obtain the requested information. In the case of identity assertion, the custom security provider verifies that the token passed in the request is valid and then generates a unique namecallback.

Multi-factor authentication mechanism

Earlier in this article, we reviewed the Web application security model. One of the problems with specifying authentication methods in the login configuration is that at a specified time, a Web application can only configure one authentication method. In some cases, however, you need to serve users from multiple sources, that is, users from trusted sources (front-end access managers) that contain defined tokens, and those that are not from trusted sources. May include users from the internal network, who can access the application server directly. In other words, depending on the source of the request, the servlet security implementation may need to generate two different callbackhandlers. However, there is no provision in the servlet specification to allow multi-factor authentication methods. This requires invoking a programmatic solution that is specific to the Web container provider. As I noted earlier, WebLogic provides weblogic.servlet.security.ServletAuthentication for procedural authentication inside a Web application. The Servletauthentication method provides two important methods for authentication:

• Weak (): After obtaining the user name and password from the request, return an int value for authenticated or failed_authentication, authenticate the user, and set it to session.
• Strong (): In contrast to the "WebLogic" (default) domain, strong authentication uses the client certificate chain as the authentication credential.

Figure 3 provides the steps for this configuration. In identity assertion, the servlet container invokes the strong () method of Servletauthentication. To implement multi-factor authentication methods (based on the Client-cert and form methods) for the same Web application, the options are included in the login form by programmatically calling the method. In other words, the login form performs strong authentication (Client-cert) first. If a valid token appears in the request header or cookie, the user is allowed access to the resource. If strong authentication fails, the login form prompts for a user name and password. It is important to note that basic and Client-cert authentication methods cannot be combined programmatically because basic forms of authentication do not provide the ability to customize authentication forms, nor do they provide programmatic capability in the form.

Figure 3 Steps when using the multi-factor authentication method

Alternative Solutions

Identity assertion is not the only viable solution to this problem. Other solutions include passing a shared secret key (or token) between two parties. In this case, both the sender and the receiver agree to the shared secret key in advance. If a request with the correct shared secret key value arrives, the receiver can trust that the request is from a trusted source and allows access to the underlying resource.

Other solutions, such as IP-based trusts, can also be used here. In this case, before the request is authorized for access, the application checks whether the request is from a preconfigured, trusted IP address. Typically, the IP of the Web server in the DMZ.

Conclusion

This article details how Bea WebLogic Server provides a mechanism to perform perimeter authentication through identity assertion. This approach is useful when the current-side Access Manager performs authentication, and multiple back-end servers believe that requests from the front-end are authenticated and require no additional authentication.

Source: http://middleware123.com/weblogic/security/520.html