Category Archives: Access Control

OpenSSO Identity Services

Posted on by

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 …).

Driver’s License to be the Next Debit Card

Posted on by

I just came across this article on Business Week “Use Your Driver’s License as a Debit Card“.

The intent is to use your drivers license for payment transactions. By coupling your license number to your bank account, they make your drivers license suitable for payments. Just swipe it, enter your personal code and the money is transfered. This way the shop owner doesn’t have to pay credit card companies those exorbitant fees and can carry less plastic around in your wallet.

Sounds like a good idea? Yes and no. Yes, since you don’t have to carry yet another card for doing payments. No, because they are overloading the drivers license to do stuff that it wasn’t made for.

We all know the the verification process for the US drivers license is shaky yo say the least on most states. The REAL ID act tries to improve this situation by introducing extra measures. But in the end, the verification process remains faulty. It is just less faulty but still faulty enough. Piggy backing a payment authorization is not such a good idea. You could couple the bank account of John to the drivers license of Jeff. And what happens if your drivers license is revoked? No payments anymore?

Their aim, reducing the number of plastic in your wallet, is worthy. Their modus operandi isn’t. Piggy backing one type of identification and authorization on to another type is often dangerous. Not always bad, but often questionable.

Why not introduce a blank card that can store multiple virtual ID cards like your credit card, drivers license … You just pick and unlock the one you would like to use. That reduces the plastic weight while still separating identities and authorization when needed and when you wish. Sounds like user centric identity in your wallet.