WLP and Single Sign On
Josh Bregman's Blog |
September 21, 2005 8:06 PM
|
Comments (0)
The first thing to be considered when designing this type of SSO solution is understanding the security/identity capabilities of the applications that you want to perform SSO. WLP has a lot of strong functionality for passing identity in a variety of fashions, but at the end the day, if the back end application only supports username and password, you'll need to pass a username and password. In many cases, back end applications have different capabilities based upon the protocol/listener that they are using, so you'll have to do some research.
In general, using a technique which does not require the passing of user passwords is preferred. The propagation of passwords to non-authoritative systems presenent not only a security risk, but creates an administrative nightmare. Increasingly, businesses require the changing of passwords on a regular basis. If the password is changed in the authoritative source, it will need to be changed in WLP as well. If the passwords are out of synch, the SSO fails.
Also, logging in to back end systems as a fixed system identity should also be discouraged. The reason is that all of the audit logs of the back-end systems will have the fixed system user, and not the actual user performing the transaction. This practice is also ripe for internal abuse. If an internal user gains access to the system user's password, they can do almost anything, with no real audit of their actions. If the system only accomodates a fixed admin user, tightly restrict access to that account, consider very carefully which operations that account can perform (read/only?), and restrict from where that account can perform operations. Ideally, this type of service would be protected by some transport level security such as mutually authenticated SSL.
I've had a lot of thoughts on this subject as its been coming up at a lot of accounts, and I'm prepping for a Birds of a Feather at BEA World on the topic. I apologized in advance for people who read this post and attend the BOF. I promise to have some new material for the session.
In a lot of accounts, there already exists an Identity and Access Management system like CA SiteMinder. In that case, if you have both the front end of WLP protected and the back end application protected, you can pass the identity through. How the identity gets passed is dependent on the I&AM solution, but in most cases, you'll be passing an HTTP cookie. Best practice here is to use Apache Commons HTTP client to pass the cookie and/or HTTP header from the HttpServletRequest to the back end app.
The reason why SAML and WS-Security is really the best approach is because it does not require the passing and/or synchronization of passwords, and both the identity of the user and the calling service can be validated. If the back end application supports these standards, then it should be auditing the actual user.
Implementing this in 8.x can be a little tricky. You can add a JAX-RPC client handler that adds a SAML assertion to the WS-Security envelope. AquaLogic Enterprise Security (ALES) has the ability to generate and consume SAML assertions, so this can speed development time. Additionally, WSRP uses this to provide SSO between WLP Federated Portlets. In 9.x web-services stack has support for WS-Security SAML Token Profile, both as a producer and a consumer.
In summary, the key to delivering SSO from WLP to back end applications is to understand the capabilities of the back end applications. If they do not support the secure passing of identity via SAML and WS-Security, other techniques are available, but they come with some risks.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
|
