Covering J2EE Security and WebLogic Topics

OWASP

Have you seen The Open Web Application Security Project (OWASP) site? If not, you’ll be amazed at the wealth of information they freely provide. Here’s a sampling:

  • Read the Top Ten Web Application Security Flaws to not only learn about common security oversights but how to correct them.
  • The in-depth Guide to Building Secure Web Applications is a must-read for any developer. It’s long, detailed, and incredibly good.
  • It’s easy to talk theory about exploits and even to code defensively for them. But nothing will drive home the concepts like actually performing the exploits. For a safe, guided walkthrough of common web application exploits, take WebGoat for a spin. WebGoat lets you play the hacker with this sample application, effectively demonstrating the problems caused by insufficient security measures and how a hacker can leverage weaknesses. It’s quite eye-opening.

OWASP also covers many other subjects related to web application security. Check it out today.

Dude, Where’s My DefaultAuthorizer?

There are some things in life a guy just takes as given — death, taxes, and the warm, comforting presence of the default security providers in WebLogic.

In WebLogic 9.1, though, the DefaultAuthorizer and DefaultRoleMapper were put out to pasture. Sort of. They’re still available but they’re not quite so default anymore. Instead, they were muscled out of the default realm by the new guys in town, XACMLAuthorizer and XACMLRoleMapper.

XACML stands for eXtensible Access Control Markup Language. Led by OASIS, XACML is a standard access control policy language. From the OASIS XACML FAQ:

Currently, there are many proprietary or application-specific access control policy languages. This means policies cannot be shared across different applications, and provides little incentive to develop good policy composition and auditing tools. … XACML enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies, “deny” policies, and dynamic policies–all without requiring changes to the applications that use XACML. Adoption of XACML across vendor and product platforms provides the opportunity for organizations to perform access and access policy audits directly across such systems.

The first sentence applies to the DefaultAuthorizer and DefaultRoleMapper which use a proprietary policy language. The last half of the quote is where we find the promise of the XACML standard.

For the typical WebLogic developer, though, it probably doesn’t matter which policy language is used behind the scenes. But since the new XACML security providers are otherwise equivalent to the ones they replace, it makes sense to use the new ones instead. One day in the future you might be glad that your policies are stored in a standard format for the cross-vendor support it provides.

RDBMS Authentication Reborn

Authentication is a concept that I covered in the popular Monty Python Teaches Application Security post. I think I need to work Monty into more posts!

Getting back to business, authentication is about proving the identity of a user requesting access to a protected resource. WebLogic provides a security framework which can accept pluggable authentication providers along with other provider types such as authorization.

BEA provided an RDBMS realm in WebLogic 6.x and prior. This realm managed users and groups that were stored in a database using a specified schema. Since everyone has a database, storing users and groups there was the path of least resistance even though performance would be better with an LDAP store.

However, this functionality was deprecated in 7.0 in favor of the new security framework. If you wanted to use RDBMS authentication you had to use the Compatibility security mode.

I can’t tell you how many times I’ve been asked about an RDBMS authenticator since the release of WebLogic 7.0. Newsgroups and forums also illustrate the pent-up demand for such a beast.

The best that RDBMS authenticator seekers could do was grab the sample one found on the BEA website and modify it. The code was unsupported, of course.

BEA must have heard developers’ cries. Like Shirley McLaine, RDBMS authentication is enjoying a newfound life in the WebLogic 9.0 release. It’s back with a vengeance, too, because there are three types from which to choose: SQLAuthenticator, ReadOnlySQLAuthenticator, and CustomDBMSAuthenticator.

So wallpaper those tables and sweep the rows — users are moving back in!

Free Bastion Blog Newsletter

If you’d prefer to get this blog’s content delivered directly to your inbox, consider signing up for the Bastion Blog Newsletter. At the end of each week I’ll send you an email containing that week’s content. Your email address will be kept strictly confidential.

Sign up for the Free Bastion Blog Email Newsletter

Besides visiting the website or subscribing to the newsletter, there’s always the RSS feed if you are interested in that approach.

A New Java, Identity Management, and PKI Blog

I just learned that my friend Steve Nakhla started blogging on Java, Identity Management, and PKI. This is a good thing because the latter two subjects are like (black) magic to many developers and Steve has been there, done that.

I’m looking forward to reading what Steve has to say on these subjects. Get busy, Steve!

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.

WebLogic with a PKCS12 Keystore

I recently tried to get WebLogic 8.1.3 Server to use a PKCS12 keystore which contained the server’s identity certificate. A PKCS12 file contains the private key and public certificate. For all practical purposes, it’s just like a JKS keystore as long as you specify the PKCS12 store type when using the WebLogic Console Keystore Configuration screen or keytool. The convention for PKCS12 filename extensions is either .p12 or .pfx.

Normally, I use JKS keystores so I was in uncharted territory although all signs indicated that it should work. As my luck would have it, it didn’t work. Upon server startup I received a “Set tag error” which prevented the SSL port from working.

As it turns out, the problem was caused by a bug in JDK 1.4.2_04. Supposedly, it was fixed in 1.4.2_05 which comes with WLS 8.1.4. However, I used JDK 1.4.2_06 and it worked just fine.

WebLogic and the Security Manager

Felipe Gaucho recently blogged about security managers with his post entitled Is the security-manager enabled in your server? Essentially, he states that most developers are either blissfully unaware of the security manager or know about it but choose to ignore it. He says:

…[T]he most popular web-servers come with the security-manager disabled. Why? The server vendors argue about the facility of disabling security-manager during the development phase and also argue about the need of a experienced technician in order to configure the correct details during the deployment into a production server. Well, I agree in part with such policy but I perceive the damage on the culture of the developers. How many times did you, developer, think about the security-manager and its functionality? If you answer almost never or if you even don’t know what this thing means, don’t worry – you are part of the majority of Java community that never has time or interest to learn about that.

With WebLogic, the security manager is disabled by default but can be enabled by specifying java.security.manager as a Java command line argument when starting the server.

When the security manager is enabled, WebLogic uses <WL_HOME>\server\lib\weblogic.policy as the policy file by default. This can be changed by modifying the java.security.policy command line argument in the startup script.

For more information, see Using Java Security to Protect WebLogic Resources.

Security Realm Logging in WebLogic 8.1

Want more debugging output than you can shake a stick at? Here’s a tip for enabling debugging output from the security providers. This output is useful when you are developing custom providers or when you are troubleshooting a problem with your security configuration.

To set this up, add the following stanza within the <server> element in config.xml:

<ServerDebug DebugSecurityAdjudicator="true"
      DebugSecurityAtn="true" DebugSecurityAtz="true"
      DebugSecurityEEngine="true" DebugSecurityRealm="true"
      DebugSecurityRoleMap="true" Name="myserver"/>

Change “myserver” to match your server name if necessary.

Then, in WebLogic Server Console, select your server in the applet. On the right-hand side, navigate to Logging->Server and enable debugging by checking Debug to StdOut and clicking the Apply button.

Restart WebLogic to have the changes take effect.

Update: Read Security Debugging in WebLogic 9 for how to do this in 9.x.

WebLogic 9.1 Authorization Gotcha

The Problem

I have a web application prototype that I’m developing on WebLogic 8.1.4 that uses simple container-managed authorization. I thought I’d play around with WebLogic 9.1 a bit so I deployed my app there fully expecting it to work just fine. I set up my users and groups in the 9.1 domain and then tried to access it.

The login screen came up but I couldn’t see the protected page after entering my username and password. Instead, I was rewarded with the login screen again. I checked and double-checked my users and groups. Everything seemed OK. I enabled auditing and saw that authentication succeeded but authorization failed.

I was stumped and outraged that BEA released 9.1 without testing container-managed security! 😉

The Solution

As it turns out, I must admit to an expedient approach I take for prototypes that saves me some typing. I usually just create several groups, throw some users in the groups, and then protect resources based on the group names. By doing this, I don’t have to mess with the weblogic.xml deployment descriptor.

I know that this descriptor can map roles to principals, but I never needed it for my simple group-based authorization cheat. The reason is that WebLogic 8.x would automatically map role names defined in web.xml to principals of the same name. Here’s the output from the server stating this:

<Jan 6, 2006 9:14:36 PM EST> <Warning> <HTTP> <BEA-101304> <Webapp: ServletContext(id=5449525,name=FancyApp,context-path=/FancyApp), the role: Administrators defined in web.xml has not been mapped to principals in security-role-assignment in weblogic.xml. Will use the rolename itself as the principal-name.>

Now, I always knew that it was doing that for me so it never occured to me that 9.1 would behave differently. It was only out of desperation that I tried doing the mapping myself in weblogic.xml as shown below:

<weblogic-web-app>

    <security-role-assignment>
      <role-name>Admin</role-name>
      <externally-defined/>
    </security-role-assignment>
 
</weblogic-web-app>

The externally-defined element indicates that the realm determines what the role name maps to. I also modified web.xml to use the role name instead of the group name. With these changes in place my application worked fine.

UPDATE: I should have pointed out in the original article that the externally-defined element allowed me to use the WebLogic Console to map the Admin role to groups. I could have "hard-coded" the mapping by replacing <externally-defined/> with <principal-name>Administrators</principal-name>, for example. This would map the Admin role to the Administrators group.

I can only conclude that the default mapping does not occur in 9.1 and there’s nothing to warn cheaters like me of the situation.

I guess WebLogic 9.1 is trying to protect lazy programmers from themselves…

« Previous Entries  

Bookmark this page on del.icio.us