Home > SAML > About SAML (Security Assertion Markup Language)

About SAML (Security Assertion Markup Language)


Starting this post I would like to post series of posts on SAML security. I’ve come across lot of folks who are fascinated by this buzz word but knew very little about what it does in real world.

One can consider this series as a tutorial and step-by-step guide to developing SAML based webservices.

 

http://docs.oracle.com/cd/E12839_01/web.1111/e13710/archtect.htm

  • Sender-Vouches – The asserting party (different from the subject) vouches for the verification of the subject. The receiver must have a trust relationship with the asserting party.
  • Holder-of-Key – The purpose of SAML token with “holder-of-key” subject confirmation is to allow the subject to use an X.509 certificate that may not be trusted by the receiver to protect the integrity of the request messages.Conceptually, the asserting party inserts an X.509 public certificate (or other key info) into a SAML assertion. (More correctly, the asserting party binds a key to a subject.) In order to protect this embedded certificate, the SAML assertion itself must be signed by the asserting entity. For WebLogic Server, the Web Service client signs the SAML assertion with its private key. That is, the signature on the assertion is the signature of the SAML authority, and is not based on the certificate contained in, or identified by, the assertion.
  • Bearer – The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using attributes that may be included in the<SubjectConfirmationData>element of the assertion.

As per http://dulanja.blogspot.in/2013/01/saml-subject-confirmation-methods.html

Bearer

This is actually not a confirmation method – means subject confirmation is not needed! The RP simply trusts whoever brings the token!

Holder of Key (HoK)
1. STS includes the public key of the client, inside the security token and signs it.
2. Then before sending, client itself signs the request.
3. When the RP receives it, it first validates STS signature and then validates client’s signature with the public key embedded inside the token.

Sender Vouches
1. Rather than authenticating with the STS, here, Client authenticates with an intermediate service.
2. The intermediary gets the security token from the STS.
3. Then it signs the request and sends to the RP.
4. RP trusts both the intermediary and the STS. So, it validates both of them.

Advertisements
Categories: SAML
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: