Covering J2EE Security and WebLogic Topics

check-auth-on-forward

What happens when a servlet (or JSP) forwards the user to a protected resource for which the user does not have authorization? According to the servlet specification, the user will see the protected resource. Surprise!

I checked the servlet specifications on this subject. Servlet 2.2 has no explicit mention of what happens during forwards or includes from a security perspective. Starting with Servlet 2.3, however, section SRV.12.2 explicitly states that declarative security does not apply to forwards and includes.

I’d prefer it to default the other way such that the container checks security for forwards and includes. Too bad for me, I guess. Fortunately, WebLogic meets the specification’s requirement by default but provides a way to check security if you want to enable it. To use it, add the following stanza to weblogic.xml:

<container-descriptor>
   <check-auth-on-forward/>
</container-descriptor>

Now, authorization will be checked for the target forward or include.

Encrypting Only the Login Page

I occasionally hear people say that they don’t want to use SSL for anything other than the login page for fear of the performance hit that SSL adds. Most recently, I came upon this post which claims to show how to implement such functionality in a J2EE web application.

While the above post seems to have some technical inaccuracies, I’m not writing to criticize it. Rather, I think it’s interesting to consider the ramifications of only encrypting the login page. The issues fall into three categories:

  • Performance
  • Maintainability
  • Security Impacts

Let’s have a look at each category in turn.

Performance

Performance is the crux of the reason to only encrypt the username and password. Developers hear that SSL adds a 30% overhead to response times, freak out, and then don’t want to use SSL or to only use it sparingly as this use case indicates. But really, the biggest hit of SSL is the initial setup of the socket. Once that is done, a big chunk of the SSL performance burden is gone. Since the socket is usually maintained until a timeout happens, multiple requests can leverage that same one-time setup cost.

Another thing to realize about SSL performance is that you don’t pay the overhead for your total response time. For example, assume that you have a dynamic page that takes 1 second to complete. Let’s further assume that 25% of that time is socket-level and 75% is making the database call and rendering the page. Clearly, I’m just fudging these numbers but you’re not going to see a 30% increase in the 650ms database access time, for example. By the same token, the more data you present (including images!) the more encryption has to be done which will take time.

Finally, a hardware SSL accelerator will go a long way toward reducing the SSL overhead. I don’t have any numbers for this but encryption in hardware will beat encryption in software any day.

Maintainability

While it doesn’t seem like this should be the case, encrypting only the login page introduces a software maintainability issue. Specifying that the login page should have a transport-guarantee of CONFIDENTIAL in web.xml will do the trick of ensuring that SSL is used for the login. No custom coding is required.

However, once the browser has switched to the SSL port, how do you declaratively tell it to go back to the clear (non-SSL) port after login? The answer is you can’t. Even though other resources defined in web.xml may not have the CONFIDENTIAL guarantee, the server will not automatically switch back to the clear port.

I can only think of two ways to switch back to the clear port — a servlet filter or links.

By using a servlet filter you could examine the request and then redirect to the clear port for anything other than the login page if the request was made over SSL. Do-able but not pretty.

The other way is to have all of your links specifically refer to the clear port with something like http://whatever/somepage.jsp. Clicking such a link will cause the request to be serviced without SSL but now you have hard-coded links all over the place. You could also build your link dynamically but then you’d have that code to maintain.

So far, we’ve talked about performance and maintainability. Now it’s time to consider the security aspects…

Security

In this section you’ll see what that 30% SSL premium buys you.

It makes sense that you’d want to protect the user’s password and perhaps even the username itself. You wouldn’t want anyone sniffing the wire and finding those goodies. But by not encrypting the link post-login, all data sent or received from that user can be sniffed. You require authorization for the user to see the data but allow anyone with a packet sniffer to see social security numbers, medical conditions, or whatever sensitive data your application handles. Shouldn’t that be kept safe, too?

Perhaps you think you’re safe because you’re not going out over the internet. That is a good thing, of course, but the majority (80% is what sticks in my head) of attacks are from insiders. Kinda risky.

You’ve now seen that sensitive data can be sniffed from the link. Here’s where it gets really interesting…

You’ve encrypted the username and password during login so that no bad guys can login as that user in the future. But since subsequent traffic is unencrypted you’ve just given away the keys to the kingdom. How’s that? Session hijacking.

Now that traffic is unencrypted, someone sniffing the network can see session IDs either as a request parameter or in a cookie. Given this information and an active session on the server, the malicious use can become the previously authenticated user and access the application as if he were the legitimate user. Scary stuff…

Summary

I think you can tell by now what side of the fence I fall on. I think the security issues alone call for SSL during and after login. That 30% premium allows me to sleep at night.

Did I forget or overemphasize anything? Please post your thoughts below.

WebLogic Security Framework Overview

I’ve mentioned the WebLogic security framework in the following posts:

However, the discussion detail was either from low earth orbit or zoomed in on a particular plugin, neither of which suitably covered the framework. Since I plan on talking more about the security framework, now is probably a pretty good time to have a look at it as a whole to see how it can meet your needs for application security.

The WebLogic security framework was introduced in WebLogic 7 and continues relatively unchanged in WebLogic 9. The framework provides a modular, plugin-based approach to handling the typical needs of application security. This modularity enables third-party providers and developers alike to create custom plugins for functions such as authentication or authorization. I’ll talk more about plugins in later.

Security Aspects of the J2EE Specification

The security framework is WebLogic’s implementation of the security aspects of the J2EE specification. As a result, it provides container-managed security features for your applications. This is significant because you may not have to write any security code in your application. Instead, you declaratively define security constraints on your resources (such as web pages or EJBs) in XML files and then let WebLogic intercept user requests to ensure that the user is authorized for access.

The container-managed security notion is from the J2EE spec, but the security framework allows for flexible configurations that don’t break the spec. That’s important because it leaves you breathing room for implementing custom security functionality while continuing to work within the confines of the spec.

Adhering to the J2EE specification buys you several things. They are:

  • Standard declarative security definitions for protecting resources
  • Standard programmatic access to the name of the authenticated user
  • Standard programmatic access for checking a user’s roles

Because these things are standard, an application you write today that uses these techniques will run unchanged on JBoss, WebSphere, WebLogic, or whichever application server or servlet engine you care to mention assuming that it adheres to the J2EE spec.

The programmatic security access methods for web applications are:

  • HttpServletRequest.isUserInRole(roleName)
  • HttpServletRequest.getRemoteUser()

and the programmatic security access methods for EJBs are:

  • EJBContext.getCallerPrincipal()
  • EJBContext.isCallerInRole(roleName)

Of course, these calls only work from within servlets (which includes JSPs) or EJBs, respectively. POJOs need not apply. However, WebLogic provides a proprietary way to get the user anywhere within the thread of a request. You can do this by calling weblogic.security.Security.getCurrentSubject(). You may also find weblogic.security.SubjectUtils.isUserInGroup(subject, group) useful. Just keep in mind that these two tricks are proprietary and won’t work in other servers.

You can find more information on declarative and programmatic security at http://e-docs.bea.com/wls/docs81/security/index.html.

The Framework

The discussion so far has been mostly about how the WebLogic security framework implements the security part of the J2EE spec. Now we can turn our attention to the actual components of the framework that make it all possible.

As I mentioned before, the security framework consists of a group of plugins which handle the various aspects of security. I purposefully used the term “plugin” to drive home the point that the framework is a pluggable solution. However, BEA refers to these components as Security Service Providers so I’ll use the term “provider” for the rest of this post.

WebLogic 8.1 comes with the following provider types:

  • Authentication
  • Identity Assertion
  • Role Mapping
  • Authorization
  • Adjudication
  • Credential Mapping
  • Auditing

Authentication providers are responsible for verifying the user’s identity. For example, an authenticator could authenticate based upon a username and password. You can have more than one authenticator at a time. You can also control both the order in which authenticators are accessed and the behavior of the authentication process with multiple authenticators by using the JAAS control flags (OPTIONAL, SUFFICIENT, REQUIRED, and REQUISITE).

Identity assertion providers are closely related to authenticators but they authenticate a user based upon a perimeter token that was attached to the request. For example, an X.509 certificate or a SAML token are examples of perimeter tokens. The significance here is that the user was authenticated by a different system and the token is a by-product of that authentication. Thus, the user is authenticated indirectly. You can have multiple identity asserters as long as each one handles a different token type.

Role mapping providers associate roles to the authenticated user. These roles can be dynamic based on the username, group, or time. You can have multiple role mappers.

Authorization providers grant or deny access to a resource by comparing the user’s roles with the resource’s security constraints. You can have multiple authorizers. Each authorizer can vote PERMIT, DENY, or ABSTAIN. Making a final authorization decision is left to an adjudicator.

Adjudication providers consider the votes of the authorizers in making a final authorization decision. For example, the adjudicator might be set to require all authorizers to vote PERMIT before access is granted. Or, one PERMIT vote and two DENY votes might be sufficient for granting access. It’s all up to the adjudicator, of which there can only be one. Otherwise, you’d need an adjudicator adjudicator. 😉

Credential mapping providers are for mapping an authenticated user to credentials suitable for accessing a back-end system via a Resource Adapter.

Audit providers allow for logging of security events managed by the other providers. You can have multiple auditors and you can set the severity level of events to log.

All of these providers are configured in a security realm within a domain. The realm also includes users and groups. These are the users and groups accessed by the providers defined in that realm. You can have multiple realms defined in the domain but only one realm can be active at a time. Changing the active realm requires a server restart.

The default realm configured in a WebLogic domain contains a group of providers that act against the embedded LDAP running within WebLogic. While it’s not suitable for production use, this LDAP server contains the WebLogic administrator user, standard roles, and standard groups out of the box.

Along with the default providers, BEA includes many other authentication providers such as Active Directory, SPNEGO, and a host of miscellaneous LDAP authenticators. WebLogic 9 introduces several more providers such as the DBMS providers. In fact, WebLogic 9 even introduces a new provider type: the Certificate Lookup and Validation provider. I haven’t tried it yet but this new provider type looks like a welcome addition.

I’ve painted a rosy picture of the security framework so far, and for the most part it does a great job. However, it does have some weaknesses:

  • Auditing has been a little weak–not in the output of the auditor but rather the control of it. It looks like WebLogic 9 has fixed some of this.
  • Since the security realm configuration is specific to a domain, all applications running in that domain have to use the same configuration of authenticators, authorizers, etc. Essentially, all providers, users, and groups must be suitable across all deployed applications.
  • Being able to configure multiple realms even though only one can be active is something of a tease. I haven’t thought through the implications of this, but wouldn’t it be great if you could specify that an application uses a particular realm? (Update: Now you can. Thanks, Matthias!)

Conclusion

The WebLogic security framework is a flexible, plugin-based mechanism for handling application security requirements. It implements the security aspects of the J2EE spec which allows for container-managed declarative and programmatic security. Finally, if the included providers aren’t sufficient for your purposes, you can create your own or buy third-party providers.

The Mysterious CLIENT-CERT

Note: This post is about one of the web application authentication methods defined by the Java Servlet specification. You can also read a larger article I wrote describing how all of the authentication methods work. It includes the content below.


The CLIENT-CERT authentication method is typically used for identifying the user by his X.509 certificate. This is a special usage of the Secure Sockets Layer (SSL) where both the server and the user are identified by their own certificates. As a result, this is a very strong form of authentication. But there’s more to CLIENT-CERT than you might realize.

Encounters with SSL on the Internet are almost always one-way authentication where only the server presents a certificate to the client. Think of ordering on Amazon.com, for example. The protocol switches from http to https and the little lock symbol appears on your browser. This signifies that the link is encrypted and the certificate presented by Amazon was trusted since your browser trusts certificates issued by Verisign. (Note: Public Key Infrastructure (PKI) and trust are beyond the scope of this post.) Even so, the server still does not know the identity of the user. User authentication is left to another mechanism such as username/password.

On the other hand, two-way SSL retains the server authentication part but adds the requirement that the client present a certificate that the server trusts. Assuming that both sides agree, the encrypted link is established and both sides are mutually authenticated via SSL. This technique is rare on the Internet since most people don’t have personal certificates. However, there is traction for two-way SSL on corporate intranets and in B2B scenarios. Once a mutually authenticated link is established, there is no further need for user authentication since the certificate already positively identified the user.

Whew, that was a lot of backstory on two-way SSL. Hopefully, though, the purpose of the CLIENT-CERT auth-method is now clear. Using CLIENT-CERT typically means that your application wants to authenticate the user via two-way SSL.

But wait, there’s more… 😉

Configuring CLIENT-CERT

Specifying CLIENT-CERT in web.xml is not sufficient for actually having the whole process work. I won’t go into details, but here are the additional configuration items you need to handle:

  • Ensure that your server has a server certificate
  • Ensure that your users trust your server certificate’s issuer (the CA certificate)
  • Ensure that your server is listening on the SSL port
  • Ensure that your users have certificates
  • Ensure that your server trusts the user certificate issuer(s)
  • (WebLogic) Ensure that an Identity Asserter handles the X.509 certificate and can map the certificate to a known user

The list above describes in general terms what must be configured for mutual authentication to work. In WebLogic, it’s an identity assertion security provider that handles X.509 certificates. The identity asserter isn’t triggered unless CLIENT-CERT is present in web.xml.

Once all of this is properly configured, the stars line up just so, and you dispose of the hair you pulled out trying to get it right, you’re ready to enjoy authentication via two-way SSL.

But wait, there’s more…

Perimeter Authentication Tokens

According to the servlet specification, the intention of the CLIENT-CERT authentication method was for two-way SSL as described above. However, BEA WebLogic not only supports the spec but expands upon it to support any type of perimeter authentication token.

With WebLogic, X.509 certificates, SAML tokens, Kerberos tickets, etc., are all examples of perimeter authentication tokens. Of the examples presented, the WebLogic 8.1 security framework only supports X.509 out of the box, but you can write or buy custom identity asserters that handle any type of token that can be presented as string. That’s pretty nifty.

And it all starts with the mysterious CLIENT-CERT authentication method.

Monty Python Teaches Application Security

There are two main components of application security: authentication and authorization. Authentication determines who the user is and authorization determines what the user can access. Both components are essential.

Some examples are in order, so let’s turn to Monty Python’s Holy Grail for inspiration. Surely you’ve seen the Holy Grail, right? It’s full of application security concepts. Well, some anyway. And they’re abstract at that, but let’s see what we can do.

King of the Who?

After coconut-clapping his way to the entrance of a castle on an imaginary horse, King Arthur asks the guards if he may speak with the lord of the castle. The ever vigilant guards immediately see that something is amiss and pick apart Arthur’s story with their expert knowledge of avian aerodynamics.

In this scene, Arthur tries to gain access to a protected resource (the lord of the castle). In application security, attempting to access a protected resource requires an authorization check. However, the system cannot check authorization without first determining who the user is. Thus, the system must first ask the user to identify himself. The guards try to authenticate King Arthur by having him prove his identity. In their estimation, though, he failed authentication and thus the issue of authorization was moot.

The most common form of authentication for applications is username and password. The username is who you are and the password proves that you are that person since, presumably, only you know it. Although you can build custom authentication logic, all J2EE compliant application servers such as WebLogic can manage authentication for you without custom coding.

Answer Me These Questions Three

Returning to the story at a later point, King Arthur and his knights seek to cross the Bridge of Death. However, an old man requires each to answer five (no, three!) questions before they can cross. Upon correctly answering the questions, the knights are allowed access to the bridge. Regrettably, some don’t make it…

In this scene, the bridge is a protected resource that the keeper is guarding. His first question is a very weak form of authentication whereby he asks each knight his name and takes the response at face value. The remaining two questions are a form of authorization.

In application security, authorization determines if the authenticated user should be allowed access to a protected resource. In J2EE, this is most often achieved with roles. The user is granted access if he has the role required by the resource.

Like authentication, simple forms of authorization can be managed by the application server without custom coding.

Hackers and Honeypots

And now for something completely different…

Admittedly, the examples above were a whimsical approach to explaining the concepts of authentication and authorization. But it got me thinking about other security concepts that can be found in the Holy Grail movie. (Yes, I’m easily amused.) The two I thought of are mentioned below.

An example of perimeter defense can be found in the scene where the Black Knight blocks Arthur’s path. “None shall pass,” says the Black Knight. Arthur, determined to pass, literally hacks his way past the defenses. This shows that a determined hacker can breach the perimeter and that defense-in-depth is critical.

The second example can be found at the source of the Grail-shaped beacon. Of all the places the Grail could be, Zoot’s castle makes it easy to find the protected, er, resources, that it contains. This is like a honeypot system attempting to study or snare hackers who are drawn to it.

Can you think of any scenes in the Holy Grail that can represent a security concept?

 

Bookmark this page on del.icio.us