Reflections 2007

2007 passed by so quickly — it’s funny how the passage of time can feel so relative. Remember back in grade school it seemed like the school year lasted F-O-R-E-V-E-R and that even the summer did, too? I distinctly remember staring out the window in third grade lamenting that school seemed so endless. That day was a bleak winter one and it apparently matched my mood. I even remember time spent daydreaming in class about how old I’d be in the year 2000. That year seemed so magical in the mid- to late-seventies. I couldn’t even envision myself at 33. I’d be so OLD! 2000 had seemed so far away and now it’s 8 years in the past.

I hope that your 2007 was a good one and that 2008 will be even better. (And maybe a little slower, too.)

On the blog front, it’s fun (for me, at least) to mention that a Google search for “client-cert” has my post The Mysterious CLIENT-CERT as the number one result. W00t! Well, at least on some days, it does. On other days it occupies the second slot but clearly Google’s algorithm is out to lunch when that happens. It’s the Schrodinger’s cat of search results.

Yikes! That looks almost identical to the list for 2006. Maybe the passage of time is slower than I thought!

Speaking of Oracle, the database company of the same name (you might have heard of them) didn’t buy BEA in 2007. But who knows what 2008 will bring. Maybe Oracle won’t destroy WebLogic if they bought BEA. I don’t know. I’ve read some opinion pieces that BEA can’t survive the onslaught of IBM and Oracle and that it’s just a matter of time before BEA is acquired. Perhaps WebLogic is the Schrodinger’s cat of application servers. Perhaps Oracle is looking for a quantum leap in their product offering. Perhaps that would make Larry say “W00t!”

Posted in Miscellaneous January 8th, 2008 by Mike Fleming | Comments Off

Digital Signatures Explained

It’s fairly easy to get digital signatures working with web services. Just pull up the docs for your web service stack and follow the directions. Some configuration here and keystores there and you’re good to go.

But just what is happening under the covers? Digitally signing something might seem like magic but it’s rather simple conceptually even though it builds on some pretty heavy theory (mostly math, ugh!). However, in this post I’m going to talk about the concepts and leave the math to someone else.

What’s the Purpose of a Digital Signature?

Before we start decomposing the mechanics of signing data, let’s first consider what we want to use a signature for in the first place.

Data Integrity

A digital signature allows the receiver to check if the data has been altered since the sender signed it. This function is performed via a cryptographic hash which I’ll talk about later.

Verification of the Sender

Digital signatures use private and public keys. An entity (person or process) signs the message with his/its private key and then the recipient can use the entity’s public key to verify the source.

Hey, you got your Digital Signature in my SSL!

Do these two functions seem a little like what SSL does? You’re right! SSL provides those features for data in transit while a digital signature does the same thing at the message level. SSL and digital signatures don’t work in the exact same way but they do perform similar high-level functions. One interesting difference between the two is that the digital signature stays with the message even if it’s sitting in a queue or on disk somewhere (assuming that it’s not intentionally stripped at some point).

Try that, SSL!

I’d like to mention one more thing about SSL and signatures before digging out of this SSL rabbit hole: You can use signatures and SSL at the same time. Why might you want to do this? There are several reasons:

You want to encrypt your message over the wire. That’s SSL’s sweet spot.

Your message gets processed by multiple machines and you want each to verify the original sender of the message. SSL can’t do this past the first recipient since it’s a point-to-point protocol. The digital signature, on the other hand, travels with the message wherever it may go.

How Digital Signatures Work

Creating signed data is a two step process. The first step is to hash the data and the second step is to sign the hash. Both of these steps are cryptographic operations but neither actually encrypts the data. Fortunately, the Java API provides classes for doing these operations so we don’t have to write any of that complex stuff. We’ll see these APIs in action in a bit.

Let’s Hash it Out

There are several algorithms for generating one-way cryptographic hashes. You’ve probably heard of MD5 and SHA-1. These algorithms take any amount of data and convert it to a fixed length byte array that can’t be reversed. That is, given the hash, you can’t determine what the input was. Additionally, two different inputs will never generate the same hash.

NOTE: Technically, both of the previous assertions are not absolutely true. The time and computing power required for reversing a hash make it unlikely. The more likely case for "reversing" a hash is to leverage a pre-computed hash dictionary which I’ll discuss briefly later. Finally, there are so called "collisions" where two different inputs can create the same hash but this situation is extremely rare).

Because of these features, hash algorithms are often used for storing passwords. Take the user’s password, hash it, and then store it in LDAP or a database. You can’t guess the password from the hash so the stored passwords are reasonably secure from prying eyes. But when the user logs in, you hash the newly supplied password and compare it against the hash on file. If they match, the user is authenticated.

I bet you already knew that stuff. The cool thing is that’s the first half of generating a signature. Before we move on to the second half, let’s have a look at how to generate a hash using the Java APIs.

The code above leverages the MessageDigest class for hashing data. "Digest" is another word for "hash." We tell the MessageDigest object that we want to use the SHA-1 algorithm and then feed it the data using the update() method. You can call that method repeatedly until all of your data is included in the hash. Then, simply call digest() to get the fixed-length hash.

Notice that the hash is actually a byte array which would create non-printable characters. So, to show you the hash for the input data I’ll first encode the hash like this:

String encodedHash =
new sun.misc.BASE64Encoder().encode(hash);

I know, I know. Don’t use the sun.* classes. I’m just saving you the trouble of not having to download something like Commons Codec in order to try this out. Just don’t use sun.* classes for production.

Anyway, now that the hash has been encoded, I can tell you that the hashed version of "Corned beef hash" is

TARd8ciquglqtzCGlhl/Ano8+kE=

Notice that the length of the hash is longer than the input. Let’s try hashing "Corned beef hash is not dog food"

H6exMsBveZPenXK756/i+ph1z8Q=

Notice that the length of the hash is still the same. It would even be the same length for a megabyte worth of text.

Before we move on to signing data, I’d like to mention one more thing about hashing. The one-way nature of a cryptographic hash is very useful but it can bite you. Since the same input always generates the same hash for a given algorithm, a bad guy who can get hold of your hashed data might be able to use a precomputed hash dictionary to determine your original text. It’s sort of like a reverse-lookup of the hash. For example, a hash dictionary will have the hashes for common passwords such as "Password" or "ABC123" and the bad guy can just query the hash to get the corresponding input.

Not good.

The remedy is to add some "salt" to the hash. A salt is just a bit of data that you’ll add to your input text when you compute the hash. This simply equates to another call to update() method. Only you know the value of this salt which acts like a simple pass key or password and negates the ability for a bad guy to determine the input data.

For example, the hash for "Corned beef hash" is TARd8ciquglqtzCGlhl/Ano8+kE= and always will be. The hash of "Corned beef hash" with a salt of "Pinch of Salt" is rEN7xxJPqyY7pkspLL902NkmJn0=. Obviously, the phrase "Pinch of Salt" would have to be kept secret.

Signing Data

Conceptually, we would now just sign the hash. However, with the Java API, the hashing is done for us as part of the signing process so we wouldn’t actually perform the steps above to generate the signature. Instead, we’d just use the Signature class.

Using the Signature class is a little more involved than hashing because we need a private key to actually do the signing. The corresponding public key would be used by the recipient to verify the signature later. Ideally, you would have your keys in a keystore and use them with the Signature class. For demonstration purposes I’m going to generate the keypair on the fly. Yes, I’m lazy but it also makes the pertinent signing machinery stand out better. Call it artistic license.

The first group of code generates a sample keypair that, as shown here, will only live until it goes out of scope. It’s good enough for our purposes, though. The second group is where the action is. We tell the Signature object that we want to use the DSA (Digital Signature Algorithm) and then we load it with the private key to use as the signer. Add the text via update() just like we did for hashing and then call sign(). Just like before, we get back a byte array which is unprintable. After encoding the signed data, I can tell you that the signature for "Sign on the dotted line" looks like this:

MCwCFA1+YXhgSu0xCP6lhKVO9QH5DYbcAhRQ/V5i8czHiMxL7SnyLtafZNoL9A==

Now, the results here are a little trickier than when hashing. If you run this code, you’ll get a different encoded string than what’s shown here. It’ll be different for two reasons:

You’re using a different private key

You’re running it at a different time on different hardware

When I run it again with the same private key I get

MCwCFBlCOnD9MfPgTtDUohfh7z/TArU7AhRqXyeSHAzzW97+ha2V5d4RDfZq8w==

So, even though the lengths are the same the output is different. By the way, the length will be the same regardless of the input size.

Pretty cool, isn’t it? There’s a lot of stuff going on in those few lines of code. Now we have signed data but how does the recipient verify it?

Verifying Signed Data

Let’s say I send you an email that contains two lines. The first line is

Sign on the dotted line

and the second line is

MCwCFA1+YXhgSu0xCP6lhKVO9QH5DYbcAhRQ/V5i8czHiMxL7SnyLtafZNoL9A==

Obviously, these lines represent the message and the signed message, respectively.

To see if I REALLY said "Sign on the dotted line" you would mash together my public key, the message, and the signed message to see if they align. That’s imprecise language for the process of determining if, given the message, the private key associated with the public key would produce the signed message. It’s sort of equivalent to the process of checking passwords using a hash as described above except the keys have been added to the mix.

As before, the first line tells the Signature object which signing algorithm to use and it has to match the algorithm that was used originally to sign the message. The second line loads the public key that matches the private key used to sign the data. (Important: The recipient does NOT and should not have your private key!)

We then load the message with the update() method. Finally, we pass the signed data to the verify() method. If it returns true, the signature is verified. Changing even one character in the message or signed data will cause verification to fail which is what you want. And obviously, specifying a public key that does not match the signer’s private key will fail, too.

To sum up verification, if the message is modified in any way, verification will fail. Somebody monkeyed with the data and you were able to detect it. That’s data integrity checking. If verification fails because a mismatched public key was used, then you know that someone other than who you expected signed the message. To my knowledge, you can’t distinguish between the two causes of verification failure.

Signing cannot prevent changes to the message, but changes can be detected

You can detect change, but you can’t tell WHAT changed

The signed message can travel with the data or can be separate (for example, in the email scenario above, I could have sent you the signed data in a separate email and told you it went with the first message)

Encryption and signatures are not the same. With encryption, you intend for the original message to be recoverable at some point.

You can think of a signature as a very fancy checksum

In PKI, private and public keys are mathematically related. The private key is only needed for signing and the public key is only needed for verification.

A salt can be a constant (but still secret) value or it can be generated randomly with each use. In both cases the verifier must have access to the salt.

Posted in PKI, Security November 25th, 2007 by Mike Fleming | Comments Off

Peter lays out the technical details of the providers as well as their differences. He then finishes with a SQL authenticator configuration walk-through.

I am surprised to see that he says that when choosing an authentication repository "…you are safest performance-wise with a database backed authentication store." I do agree that databases are typically well-understood by developers but I’d think that an LDAP server would kick the tail of a database in the speed department.

Anyway, that’s a tiny nitpick on an outstanding article. I encourage you to have a look.

Maven and WebLogicMBeanMaker in WebLogic 9/10

In WebLogicMBeanMaker and Maven I wrote about how to use WebLogicMBeanMaker 8.1 in a Maven 2 build. Even though WebLogicMBeanMaker is documented as a two-step process, the Maven build process allowed us to skip the second step by relying upon Maven’s packaging mechanism. All was well at the time…

Of course, if you have a security provider in WebLogic 8.1 you’re probably going to migrate it to WebLogic 9 or 10 eventually, right? Unfortunately, the old build process is no longer sufficient and you’ll have to make some changes. First, I’ll describe the problem and then show the solution.

Home is where WebLogic is

If you use a POM similar to the one presented in WebLogicMBeanMaker and Maven but with WebLogic 9+ dependencies (note that wlManagement.jar changed to wlManagementMBean.jar in WLS 9), you’ll get the following error:

“Error in finding weblogic.Home” is the only thing of value in the exception, but what’s that about? Running setDomainEnv before running Maven didn’t help.

As it turns out, the WebLogic dependencies are location-dependent in some fashion. Simply having weblogic.jar and wlManagementMBean.jar in your Maven repository is not sufficient. While setting a weblogic.home system property has potential, I didn’t have any success with the approach. What did work for me is to use the WebLogic installation directory even though it is less than ideal. Here’s how I configured my dependencies in the POM:

Essentially, I changed the scope from “provided” to “system” and added the systemPath element which points to the jar in the WebLogic installation directory. I left the hard-coded paths for illustration but you’ll probably want to use properties, instead.

Using the system scope solves the home problem and your provider will build without error. It won’t actually work, but your build was successful so what more could you want? Seriously, that problem will be solved in the next section, but for completeness, I’d like to point out something in case someone knows a better solution than using a WebLogic installation directory. After all, I’d much rather use the Maven repository and I’m guessing you would, too.

Exception in thread "main" java.lang.RuntimeException: error in finding weblogic.Home
at weblogic.Home.getInstance(Home.java:90)
at weblogic.Home.getHome(Home.java:105)
at weblogic.Home.main(Home.java:113)

I’m not sure what it means or how to leverage the information but it seems to be the root of the problem. I got tired of messing with it but if you have an idea, please comment.

Moving right along…

Scheming Minds

As I mentioned above, you should now have a JAR file for your provider. If you copy it to the mbeantypes directory and start WebLogic, though, you’ll find that your provider doesn’t show up in WebLogic console. Very annoying, indeed.

As it turns out, our pals at BEA are messing with our heads. Starting with WebLogic 9, you need to dance the MBeanMaker Two-Step because the second phase — which just jarred the provider in the past — now creates schema files among other things. No schema files means no recognition of your provider by WebLogic.

Fortunately, the solution is pretty simple since you just need to run WebLogicMBeanMaker twice to get all of the required artifacts. Here’s my updated POM snippet:

Now, in addition to the original files, your jar should contain roughly a dozen more files, half of which are XSB files. Your provider should now be recognized by WebLogic after you copy the jar to mbeantypes and restart WebLogic.

Can you handle more good news? The same build configuration works in WebLogic 10.

Update: Alex Rykov figured out how to handle the Weblogic home problem. Check it out here.

XSS and Web Frameworks

Matt Raible recently blogged about Java Web Frameworks and XSS. The post and the comments are well worth reading. It’s easy to think (hope!) that a framework will automatically escape output to prevent XSS and give no more thought to it. As Matt’s post shows, you really need to know how your chosen framework deals with the issue.

If you use Struts 2 or WebWork be sure to read the post and update your libraries.

RoleManager Audit Events in WebLogic

Want to fill up your audit logs quickly? Set the auditor’s severity to INFORMATION and you’re well on your way. In this post we’ll take a closer look and see if the information gained is worthy of the disk space and processing time.

More is Better, Right?

It’s natural to expect that audit logs won’t be as "chatty" as application logging. After all, you’d typically only expect one or a handful of authorization events for each accessed resource. Application logging, on the other hand, might spew dozens of lines per request depending upon the logging level.

With this in mind, your security officer or well-meaning admin might see that the WebLogic DefaultAuditor is initially set to a severity of ERROR leaving not one but TWO severity levels untapped. More security data has to be good, right?

Not necessarily. Besides INFORMATION, the other severity level below ERROR is WARNING. I’ve never seen a WARNING event from the out-of-the-box providers. That’s not to say they don’t exist — just that I’ve never seen one. The INFORMATION severity is the lowest level which only seems to include a certain class of Role Manager events.

Role Manager audit events can be sourced from a Role Mapping provider or an Authorization provider. Useful Role Manager events can happen at the SUCCESS and FAILURE levels, but the INFORMATION-level events are highly repetitive and provide little bang for buck. Here are a couple of examples:

As you can see, there’s very little actionable information here. Yes, user "weblogic" did something but we’re not quite sure what.

Crunch the Numbers

To give you an idea of the volume of Role Manager events at the INFORMATION severity, I started up a WebLogic 8.1 domain which includes five custom applications. I then logged into console but went no further than the initial page. Here’s the breakdown of audit events (note that I’ve enabled configuration auditing):

Authentication:

2

Authorization:

6

AuthorizationPolicy Deploy:

25

Invoke Configuration:

1

RoleManager:

772

RoleManager Deploy:

3

Set Attribute:

10

As you can see, the RoleManager events account for 94%(!) of all events for my scenario. Hitting Refresh on the console caused approximately the same number of Role Manager events. I haven’t timed it, but writing all of those events to disk is probably quite measurable.

Console makes heavy use of JMX so I suspect a lot of the Role Manager events are caused by that. I tested a "normal" web app with just a protected page. Here are the results:

Authentication:

1

Authorization:

1

RoleManager:

14

Thus, for one request, the Role Manager events comprise 88% of the total number of events. The information is slightly different (and maybe even a little useful) as long as you don’t mind seeing it a bunch of times. Here are a couple events:

I suspect these are sourced by the authorization provider given that it’s showing the requested resource information. The list of roles is barely useful — which one is required?

Quantum Logging

If you decide to not use the INFORMATION severity you can still get the equivalent information from the audit log if you had to. The first thing to consider is the Authorization event. Here’s the event that accompanied the RoleManager event above:

Notice that the resource information is identical to the equivalent RoleManager event.

How can you know which role was required for "/users/users.jsp?" One way is to check that application’s web.xml. However, that data could be newer than what was in place when the event was logged (e.g., web.xml was updated and the app was redeployed after the event).

A better way to do it is to find the most recent corresponding Authorization Policy Deploy event prior to the authorization event in question. For example,

shows one of the policies for the ImplicitGroupsApp. Note that the policy applies to "/users/*" and requires the "user" role for URIs with that pattern.

This concludes our little romp through an audit log. If you choose to not select the INFORMATION severity you can save yourself considerable disk space while still retaining the ability to get the data you need.

Recording WLST Scripts in WebLogic 10

As I mentioned in my WebLogic 10 Released post, WebLogic 10 has the ability to record your sessions in the console as WLST scripts. Unfortunately, doing so takes all the excitement and mystery out of sleuthing around for MBean information!

Even though it was deprecated in Weblogic 9, weblogic.Admin is still around which means you can still use the techniques described in Find WebLogic MBeans with Ease and Using Audit Logs to Make Scripting Easier. Furthermore, the approaches given in those posts give you the real object names of the MBeans in case you need to do some JMX work. Otherwise, WLST is the way to go for normal server configuration. The rest of this post will be a quick walk-through of the new script recording feature.

The first thing you’ll notice when you load the WebLogic 10 console is that it looks very similar to the WebLogic 9 console. You’ll also quickly notice the disabled “Record” link and the “Record WLST Scripts” link under “How Do I…” The simple steps below illustrate how to record a configuration script:

Click the “Lock & Edit” button

Click the Record link which is now enabled. A message like the following is displayed:

The recording session has started. Recording to C:\BEA10\user_projects\domains\Test\AddAuditorScript.py.

Configure whatever you want in the console. I happened to add an auditor. When you’re done, go to the next step.

Click the “Activate Changes” button

Navigate to Preferences->WLST Script Recording and click the Stop Recording button. You can also see the contents of the script file on this page. For adding an auditor and setting the severity, my script file looks like this:

At this point you can edit the script (outside of console, of course) or do whatever you need to do. Then, you can subsequently run the script as you would any WLST script.

If you are interested in recording scripts, you should read the “How Do I” link since there are some things the recorder won’t do. For example, it won’t record the addition or deletion of users, roles, or policies. You can also learn about how the recorder handles encrypted values.

Finally, if you’re running Weblogic 9 and wish you could record scripts, look no further than the WLST Script Generator. At the other end of this link you will find Satya Ghattu‘s script generator and accompanying console extension for WebLogic 9. Thanks to Andre Glauser for passing along the link.

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: