Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Perimeter Authentication via Identity Assertion

Where the back end trusts the front end

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
  • More Stories By Sudhir Upadhyay

    Sudhir Upadhyay is currently with Architecture and Shared services at JP Morgan Chase where he is an application architect. Prior to joining JPMorgan, he was a principal consultant with BEA Professional Services where he helped customers design and implement enterprise J2EE solutions. He is a BEA Certified WebLogic Developer and a Sun Certified Java Developer.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
    Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...