Josh Bregman's Blog

Josh Bregman's Homepage
Josh Bregman is a principal security technology specialist for BEA. He supports customers and the BEA field for security across all of the BEA products. Prior to joining BEA, Josh worked at Netegrity for over 5 years where he served in a number of engineering, architecture and consulting positions.

A lot of interest in security at BEAWorld

I think the real "ah-ha" for people was seeing the AquaLogic Enterprise demo. One of the real challenges with understanding security is placing it in a business context.

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.

WLP and Single Sign On

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.

Continue Reading...

Shameless Plug for My Talk at BEA World

Regardless of the actual presentation title, I'll be speaking on Tuesday, September 27th in the afternoon. The purpose of the chat is to try to share some of my experiences over the past year in support of the AquaLogic Enterprise Security Product.

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

October 2007

Search this blog:

Archives

September 2005

Categories

Recent Entries

A lot of interest in security at BEAWorld

WLP and Single Sign On

Shameless Plug for My Talk at BEA World