I have been meaning to do a blog post on this front for quite sometime but just haven't had the cycles. So this a very rushed blog post - please excuse typos!!
The basic question that seems to come up is when to use an STS in general and OSTS in particular. So here are my thoughts on the matter.
To me there are - three main scenarios for using a STS:
- Token Exchange/Conversion
- Federation
- Centralized Trust
In this post I will cover Token Exchange and Federation very briefly.
Token exchange/conversion
So the first set of scenarios is around the need to be able to exchange one kind of token with another type of token. Ex: You want to exchange a Kerberos Token with a SAML token. Here is a picture that demonstrates this scenario (click on the image for a large image):
In the above scenario a customer has a Desktop Application (ex: Say Outlook or some other .NET Web Service) that is talking to a backend Web Service let's say hosted on Oracle Fusion Middleware that can accept SAML Token.
User "joe" logs into his Desktop and a Kerberos Ticket is created. When user opens the Desktop application and performs an operation this results in a backend web service call and we want to propagate the identity of "joe" to the backend application. However the token we have is a Kerberos Token on the client side and the backend Web Service only accepts a SAML token. One can use an STS to do a token conversion or token exchange (assuming the STS is capable of such a conversion).
Web Service Federation
The second scenario where a STS is very useful and probably the most important scenario in my mind is when you need to do Federation. For those of you who are not familiar with Federation - I suggest reading up on Federation in general and Web Service Federation in particular. The picture below depicts this use-case.
The use-case is similar to a Token Exchange use-case. We have a Desktop Application (say Outlook) that needs to invoke a backend Web Service. However the backend Web Service is running in the Cloud (Public or Private Cloud).
The key issue here is that the user "joe" is unknown in the Cloud.
There is a good reason why the user "joe" is unknown in the Cloud. Since an application running in the cloud may be used by multiple customers say "Acme Inc" or "Foobar Inc" both of which may user called "joe" the Cloud cannot have a single user named "joe" in it's Directory instead it would need to distinguish "Acme Inc" user "joe" (let's call him "acme.joe" ) from "Foobar Inc" user "joe" (let's call him "foobar.joe" ).
So now in the Cloud we actually have two users "acme.joe" and "foobar.joe" - so the Desktop Application (running within Acme Inc) needs to map "joe" to "acme.joe" - before it talks to the Cloud. This mapping is where an STS comes in handy! as shown in the picture.
So not only are we converting the token from Kerberos to SAML we are also now mapping "joe" to "acme.joe" in the STS.
- The picture depicts Oracle Public Cloud - but the concept applies to any Cloud (Public/Private) or in fact across Partner systems.
- The picture depicts Fusion CRM - but the concept applies to any Web Service
- I make no guarantees that what is shown in the picture above is necessarily what is implemented in the Oracle Public Cloud and I have used the example for purely illustrative purposes!
In a future blog post I will elaborate further on some of the scenarios and also the Centralized Trust scenario.
Finally - one last parting shot - the scenarios and use-cases for an STS and OSTS are fairly extensive and in this blog post - I am trying to illustrate some very simple scenarios. Please consult the Oracle STS documentation for all the features.