OpenSSO and the role of web based SSO

P.T.Ong recently posted his thoughts on the newly announced released of OpenSSO (formerly Sun Java Access Manager which they have now open-sourced).

In his post he raises the point:

“The biggest challenge in rolling out these systems is that you had to
integrate it to the backend servers, resulting in very slow deployment
projects”

I have been deploying web based access control systems for a number of years now and have a couple of thoughts on this.

Firstly, I think it is a mistake for people to see the web based access control (WBAC) products from the traditional vendors(Netegrity (now CA), Oblix (now Oracle), Sun, IBM etc etc) as purely SSO products. Which SSO is one of the features, it is not the only purpose of these products. As well as providing an element of SSO they can also handle the authorisation for access to the applications. I won’t go on to list all the other benefits that they provide (such as centralised management and centralised auditing) as i’m sure you are aware of their capabilities. One of the problems with touting a product as an SSO product is that customers think that you install it and it magically provides SSO to everything under the sun with not changes necessary at their end. With WBAC products this just isn’t the case. As P.T. Ong eludes to there is an element of integration work which usually must be undertaken, unless you application happens to already support external authentication mechanisms.

The second issue I have when people are deploying WBAC systems is that they quite often install the software and then try to retro-fit every web based application under the sun into this new product. Whilst this is an admirable idea, the effort normally required can be quite immense. You also find that the customer will try to integrate an application that may be used by 2 or 3 people in the organization or try to integrate an application that is due to be replaced in x months. By adopting a pragmatic approach, a successful deployment can be achieved. Being realistic, looking at integrating your key applications is a good idea. Then, not only are you providing benefit for those key applications but you now have a central security platform that can be used by the developers of the new applications. You can also ensure that any new web based application that are bought off the shelf are compatible and integrate with your new security infrastructure.

Deploying a WBAC is about building a central security framework that can be used across the organisation for not only SSO (i.e authentication) but also for authorisation and auditing. If you bear this in mind, your deployment will be much quicker and more successful.

Technorati Tags: security, sso, single sign-on, web based access control, access control, opensso, identity, authorization, authentication

DON’T FORGET MY BLOG HAS NOW MOVED TO HTTP://BLOG.PDTOAL.COM

OpenSSO and the role of web based SSO

P.T.Ong recently posted his thoughts on the newly announced released of OpenSSO (formerly Sun Java Access Manager which they have now open-sourced).

In his post he raises the point:

“The biggest challenge in rolling out these systems is that you had to
integrate it to the backend servers, resulting in very slow deployment
projects”

I have been deploying web based access control systems for a number of years now and have a couple of thoughts on this.

Firstly, I think it is a mistake for people to see the web based access control (WBAC) products from the traditional vendors(Netegrity (now CA), Oblix (now Oracle), Sun, IBM etc etc) as purely SSO products. Which SSO is one of the features, it is not the only purpose of these products. As well as providing an element of SSO they can also handle the authorisation for access to the applications. I won’t go on to list all the other benefits that they provide (such as centralised management and centralised auditing) as i’m sure you are aware of their capabilities. One of the problems with touting a product as an SSO product is that customers think that you install it and it magically provides SSO to everything under the sun with not changes necessary at their end. With WBAC products this just isn’t the case. As P.T. Ong eludes to there is an element of integration work which usually must be undertaken, unless you application happens to already support external authentication mechanisms.

The second issue I have when people are deploying WBAC systems is that they quite often install the software and then try to retro-fit every web based application under the sun into this new product. Whilst this is an admirable idea, the effort normally required can be quite immense. You also find that the customer will try to integrate an application that may be used by 2 or 3 people in the organization or try to integrate an application that is due to be replaced in x months. By adopting a pragmatic approach, a successful deployment can be achieved. Being realistic, looking at integrating your key applications is a good idea. Then, not only are you providing benefit for those key applications but you now have a central security platform that can be used by the developers of the new applications. You can also ensure that any new web based application that are bought off the shelf are compatible and integrate with your new security infrastructure.

Deploying a WBAC is about building a central security framework that can be used across the organisation for not only SSO (i.e authentication) but also for authorisation and auditing. If you bear this in mind, your deployment will be much quicker and more successful.

Technorati Tags: security, sso, single sign-on, web based access control, access control, opensso, identity, authorization, authentication