I get points for wanting to help though!

Take care Tim,

Jeremy

One thing I am considering is generating an encryption key at start up of an authentication server known only to it. When an authentication operation completes, the result would be a ticket. The ticket would basically be an encrypted value representing the username and additional information to facilitate expiration and uniqueness over time (any token that doesn’t change is inherently insecure). When provided with that information, the authentication service would do a lookup by the decrypted username to retrieve cached principal information. The principal cache would either be refreshed at a time interval or updated through event propagation.

Ideally, I would like to find an open source ticketing server that plays well with all the various technologies in the system (Mule, Spring, JAX-WS, CXF, etc.). I feel like I understand the difficulties of security conceptually, but I always try to leverage experts when possible. Just keeping up with what encryption algorithms to employ is a moving target with all the continual advances in attacks.

I would say, that one of the best methods, is a combination of SSL, and a token that is generated on the farthest back SOA server from the DMZ, after the user has been authenticated with username/password, or some other method. That way, the “authenticated” state is established by a more secure server, and the username and password aren’t continually being sent back and forth, which is ideal.

Any thoughts?

I have seen cases where the username was the only thing that meant anything, and the token was essentially a pre-shared value known to the client and server and written into Java code (identical for all users!). That type of implementation would only even approach feasibility if the users were never logging in themselves, but some sort of automated system was using the web service on their behalf.

Clearly, a token generated by an authentication of principal/credential on the first request is a much better system. I would still caution against using that approach without an SSL transport unless you have expiration rules built into that token (such as a nonce).

Although there are definitely holes in some of the approaches I have seen, most of them could be rationalized if they employed some sort of securing of the message, be it an SSL transport, message encryption, or both. I know in many cases, the message itself might not be secure due to the nature of the business–something like a pay-per-result public web service with fairly mundane inputs and outputs. In this case, the truly secure data is the username and authentication information as those are tied to billable events. These are the cases where expiring tokens and other aggressive strategies should definitely be employed.

As with all things security, I would advise looking at your implementation and trying to think of the worst things that could go wrong. If you are working for a high-profile organization or project, it is just a matter of time until someone exploits it. I have even seen security holes intentionally exploited by integration partners because it made the implementation easier.

Best of luck, and feel free to comment again. I hope this was helpful.

I have seen some pretty primitive attitudes toward web service security–things like non-SSL transports combined with a simple authentication token that never changes. This is exactly the kind of recklessness I wanted to avoid in my services.

What exactly do you mean by the bit about “simple authentication token”?

Do you mean like a mutually defined token, used on the web service, and the client?

Or do you mean a token generated by an authentication of principal/credential passing on the first request?

Thanks.

Raven Symones Baby …