OpenSSO (Sun’s attempt at open sourcing some of there access management solutions) has published a first draft of some Identity Services. It’s a four part article with the first two parts already published: authentication and authorization.

When I first saw this announcement, I was very interested and almost rushed over to those articles. After a first read however I was somehow disappointed. The interface definitions are very simple, a little too simple. The authentication API merely allows you to send over a username and password and it’ll return you some kind of subject identifier. The authorization API suffers from the same faith: feed it a URI, an action and a subject identifier and it will tell you if that subject is allowed in or not.

Everyone who knows something about the specifications and standards surrounding Identity Services, know that there is more to it. A lot more. You can leave stuff out to make things simpler, but I have this feeling OpenSSO has left out too much. Some of the things I feel are missing or not that good:

• Abstraction from authentication methods, it’s just username and password now. Aren’t we all working very hard to get rid of those? What about SAML, WS-Trust tokens …
• Proper countermeasures for obvious threats like replay, message insertion, message modification, message deletion … Please, don’t answer “oh, we’ll just apply SSL to the transport”, that gives you only part of the solution. You do need controls at the message and API level as well.
• The ability to tie authentication to a certain context (just returning a subject identifier leaves that aspect to the calling party). What if I would like to bind a positive authentication to a particular resource? The subject identifier might contain that information, but their specification is very silent on that aspect. For the moment, that identifier is an opaque handler.
• The returned subject identifier is currently used to bind all services together, but the specification doesn’t say how it is protected and how I can verify it’s validity. If these services are placed on the Internet, I see a lot of security holes.
• What about time windows for the validity of the authentication?

And finally, I wonder why these Identity Services from OpenSSO don’t attempt to place a higher level API around what we already have from OASIS (SAML, WS-Security, WS-Trust, WS-SecureConversation …) and Liberty Alliance (ID-FF, ID-WSF …).