OpenSSO Limitations?

1 minute read

‘Marty’ (I’m guessing this is Marty Heyman of Symas) has posted an entry regarding OpenSSO. I can’t see a way to post comments or respond in any way on Marty’s blog, so I’ll do so here. Marty says

[…] OpenSSO … from the same blog … Web SSO, Of Course. You knew that.It’s a centrally controlled service that creates and mainains a verifiable user session and creates an audit trail. Applications use the central service to verify that the user is in session and to report audit events [from the architecture document).

Let’s see, you have to modify every app to use the service, like that’s going to happen, and you’re going to introduce another single point of failure server.

If you read a little more of the linked architecture document, you will discover that OpenSSO uses agents to SSO enable web containers. The agent is essentially a filter that refers to the central service to determine the user’s identity and whether she should be given access to the requested resource. Section 4 of the architecture describes this in the context of OpenSSO. The reference to ‘applications’ as well as agents recognizes that any application accessed via HTTP can participate in SSO. So yes, if you have a custom HTTP app, you’ll have to do some enabling. If your app runs in a web container you just have to deploy and configure an agent. Access Manager (OpenSSO’s ‘parent product’) provides agents for a huge variety of containers. We will be releasing the code for a couple of agents into OpenSSO in March.

Marty goes on to say

Under Limited scope of SSO we find “web applications that are hosted on servers that do not reside in the domain of OpenSSO services deployment will not be able to participate in SSO” …. a small and probably disqualifying limitation. Children and their toys.

I would hardly describe OpenSSO as a toy - it is based on Sun’s Java System Access Manager. OpenSSO provides SSO across systems in a single domain, so you could SSO across www.example.com, www.subdomain.example.com, hr.example.com etc. This limitation is a consequence of the cookie-based implementation that OpenSSO uses - cookies only work within a single internet domain. To cross domains to, say, www.partner.com, you need federation. Federation capability is not currently in the OpenSSO roadmap.

Updated:

Comments

Marty Heyman

Pat, good and fair reply. Yes, I’m that Marty. I didn’t mean to say that the Sun technology is toy technology. The underpinnings are very respectable stuff that people should take seriously. The toy comment was about the limitation to a domain (no matter how flexible). That limitation, in the context of what the user actually wants (Single Sign On, one password), is quite restrictive. We at Symas did a demonstration of an SSO capability for one of the household-name security ISVs several years ago. Long story. Best told over adult beverages. We put it up as MySSO.com (no longer available). It demonstrated cross-domain Web single sign on based on an LDAP directory. It had its own limitations. The client couldn’t always identify login “fields” and we were endlessly tinkering to keep it working. But it did work on a wide variety of popular Web sites and we used it for a long time with great success. MySSO.com didn’t rely on cookies. It used LDAP sessions that could be easily and strongly secured and worked with the existing authentication mechanisms on the sites. It did not require adoption of an authentication technology by the Web. The technology was on the user side. Symas felt (feels) it is important that the apps need not be changed. We believe Enterprises won’t rework existing apps (Web or otherwise) and that security / Identity Management has to support what is, not what could or should be. I (we) measure Web SSO approaches against MySSO.com. It was too limited, in our experience, to be satisfying. Without a solution for the rest of the sign-on problem (email, database, legacy non-Web apps), we feared that adoption would be limited. We liked MySSO.com but it wasn’t enough, even for us. It turned out, in the end, to be a toy and we turned our attention to OpenLDAP and the challenges of the Enterprise Directory Services platform for the time being.

Arvind Prabhakar

Marty, I am the author of the document that you have quoted in your blog, and feel obligated to share my thoughts regarding the three issues that you bring up in your comments.

As stated in the architecture document (Section 2.3.4), the distribution transparencies are a core architectural concern. This concern is addressed by the service distribution, cluster and client views (Sections 3.3, 3.4, and 3.6) which provide location, distribution, replication and concurrency transparencies within the OpenSSO infrastructure.

Identity services built on top of this infrastructure are therefore fully distributed and can be sized/scaled to accommodate any practical level of volume and availability as needed for the deployment. This, in other words, implies that there is no one central service that can become a single point of failure. Of course, one could deploy OpenSSO with zero redundancy, in which case all services become single points of failure, but that is not a limitation of the system. That is the limitation of a poorly thought out deployment.

On the client side, OpenSSO provides client libraries that you could use within your application, or SSO Agents that could be installed to seamlessly integrate your application platform with OpenSSO. The SSO Agents, defined as 'a minimally intrusive transparent software component that can be added to the access path of a web application to allow it to participate in SSO', facilitate the inclusion of OpenSSO services without requiring the hosted applications to be modified. As Pat points out, these SSO Agents are on their way to be released very soon. If you refer back to the architecture document, you would see the mention of SSO Agents in virtually every architectural view, and is hard to miss.

Lastly, I wish to emphasize that OpenSSO has a layered architecture with minimal coupling between layers and mature interfaces for inter-layer communication. As such, you could virtually replace or enhance any portion of OpenSSO system with your own extensions and implementations. Incidentally, the use of a domain cookie based single sign-on is just one such implementation. If you compare it with Access Manager, you would note that the later can be configured to provide multiple domain single sign-on capability while using host cookies (yes, I said host cookies and not domain cookies). It even goes as far as providing cookie-less single sign-on using URL rewriting if that is necessary for any deployment. It also provides single sign-on and integration with Java 2 Security framework outside of Web infrastructure. As you can see, this list is endless. If you adopt this solution, the only serious limitation that I would caution against is your imagination. The rest we take care off pretty well...

Marjon Roodzant

It may be a good idea to have openSSO not refer so much to the SAM7 documentation. We were convinced, based on this, that OpenSSO also provided the CDSSO capability. And it is quite a blow that it does not, i can tell you.

Is there no way around this?
greetings
Marjon

Leave a Comment

Your email address will not be published. Required fields are marked *

Markdown is supported.

You May Also Enjoy