Sunday, September 29, 2013

Security Token Servce concept

Simply - as the name also clearly implies - Security Token Service (STS) is a service which issues tokens regarding users (aka subject/principal).

This is an important part of identity federation, as such, it removes the burden of maintaining identity information across domains.

How does it removes that burden...exactly??

Let's first enter to a world without an STS...

When User-A1 from Domain-A tries to access Service-B of Domain-B, in order to grant access, Service-B should have a way to authenticate (and authorize) User-A1.

To do this, Domain-B should have User-A1 in the userstore. For each User-A1 --> User-An this has to be done.

Now here's the issue...

Maintaining User-Ablahblah details simply to grant access to ServiceB should not be DomainB's business. It's so much additional and unnecessary work. Also DomainB is totally unaware of the new users created in DomainA (unless some sort of identity provisioning exists. burden^2)

Here enters the STS!

Service-B: "If you want to access me, bring me a token from STS-A"

Service-B trusts STS-A of Domain-A, and that's it! Domain-B doesn't maintain any information regarding users of the other domain so it has no clue who the User-A1 is.

So, when that user wants to access Service-B, he should first authenticate with STS-A which resides in his own domain and get a token from it. Then he should present that token to Service-B.

Service-B might requires some attributes (aka claims) of User-A1 in this token for its authorization purpose. This might be the age, email address or any such detail. If the required details are present, ACCESS GRANTED!

voila! User management burden eliminated!


No comments: