The demo, for those who missed it, presented a commercial banking scenario. The scenario is a father granting limited access to his college age daughter. The father establishes limits on how much the daughter can transfer from her fathers account without approval or providing a PIN. All of the entitlements data is stored inside of ALES, and the approval workflow is driven by WLI.
In addition, ALES protects users access to WLP resources such as Portlets, Books, Pages and Desktops. The ability to protect both J2EE resources and business objects, like accounts, from a single console was compelling for many customers.
Besides spending time in the ALES booth, I presented ALES as a foundation for a service oriented security architecture. About 100 people were in attendance - I appreciate everyone spending time with me, and asking some really really good questions. The most interesting development in this area is the realeas of the web-services SSM - this exposes the core authentication, authorization, roles etc services of the SSPI as SOAP services.
A common scenario here is the need for a single service which authenticates a user with username and password, and then returns all of the roles that they have. By starting with ALES and the authentication and roles service, this service can be simply configured by building a proxy service with ESB.
Personally, it was my first BEAWorld, and I had a really good time. I spoke with a lot of customers/partners and am looking forward to following up with them in the coming days,weeks, and months.
]]>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.
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.
]]>I've been travelling quite a bit (Delta Silver/UsAir Silver/Marriott Silver) and there is really quite an interest in this product. I think the message to developers is that they no longer have to worry about keeping up with constantly changing security requirements. In most applications, the security logic is hard-coded into the applications. By that, I mean that decisions about who can get access to what is ultimately determined by application code, not by a centralized security service. Certainly, enterprises have some notion of entitlements - RDBMS based systems that maintain profile data - but at the end of the day the decision is being made inside of the application.
Externalizing this logic is certainly easier said than done, but there are certainly some techniques and approaches which can make this less painful. Some will be covered in the presentation...others will be covered here and hopefully in some code samples etc in dev2dev itself