Live from JavaOne: Identity for Services in the Cloud

The next talk was about Identity for Services in the Cloud, by Jiandong Guo and Symon Chang. Their focus was to promote their favorite solution, which has been around for a while, and whose objective is to clearly separate authentication from authorization using standards. Their scheme is quite classical:

  • The client gets a SAML token from Security Token Service (STS) using WS-Trust protocol.
  • The client puts the SAML token into the message.
  • The server verifies SAML token and makes authentication and authorization decision.

Of course, the actual authentication occurs in the first step, between the client and the STS. After that, it is all a question of trust between the server and the STS that has generated the SAML token. With this scheme, we can avoid direct authentication between the client and the server.

Nothing really new, but I really liked their explanation, based on a parallel with the JavaOne conference badges. When you arrive to JavaOne, you first go to registration. There, you need to prove your identity by showing an officla ID to the attendant, who will then prepare the badge that grants you access to the conference. In addition, the attendant will add some ribbons that describe your specific attributes. For instance, I have the “Speaker” and “Alumni” ribbons. These ribbons are attributes that complement your basic identification, and allow you to get authorized in some circumstances. For instance, I can get into the speaker lounge, and I got an alumni jacket.

The conference badge acts like a SAML token: the basic badge shows that you have been authenticated, and the additional attributes describe some of your characteristics.

The model can be slightly enhanced by using two levels of STS. The idea is that the user will get a SAML token from a local STS, and use that token. The server will then get that token to another STS (local to the server), and get in return another SAML token, suited to its needs. With this scheme, both the client and the server only need to trust a single STS. The business of trust is entirely delegated to the two STS’s, who need to share each other. This clearly separates the trust issues from the rest.

Interesting presentation, but I still don’t feel enlightened about identity in the cloud. There is another session tomorrow on the topic, I hope that I will be thrilled.

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *