Durable Tokens Across Services - Share your tokens
There seems to be quite a number of time when you want to perform your authentication once and then you just go ahead the want to just call a service without performing the authentication again.
What are some advantages of this ?
1. You get to manage your authentication independently. - Also results in a single point of failure.
2. You can build solutions that can leverage an existing authentication framework and save time building that
3. You could have many services talk to each other and share credentials across and build connected systems as they don't have to manager user bases or authentication stores independently. Still there are dependency on user details but the application is freed from worrying about the actual authentication scheme.
4. And many more depending on your scenario :)
The SDK already has a DurableTokenSecurity Sample and in this post the only modification to that is the way the token cache is built on the client side. If you haven't yet understood the sample, then the you need to understand how the token is picked up and cached and replayed back.
Understanding Durable Tokens
The endpoint has a ClientCredentials behavior. You have to remove the default behavior and slap on your own. the client credentials is also responsible for retrieving the credentials for a service and sending it out with the service request.
factory.Endpoint.Behaviors.Remove<ClientCredentials>();
factory.Endpoint.Behaviors.Add(durableCreds);
The durable credential extends the ClientCredentials and has a reference to the cache that supplies the tokens and stores the token. The SDK sample comes with multiple forms of cache. A file cache and in memory cache. You can choose what cache you would like as they have the separate uses.
Next step would be to understand how the cache is used. The DurableIssuedSecurityTokenProvider implements the SecurityTokenProvider which is responsible for retrieving the token from the cache and uses the instance of the cache that is provided and calls the Add or TryGet that queries the concrete implementation of the cache. The GetTokenCore is what is used to retrieve the token from the cache.
protected override SecurityToken GetTokenCore(TimeSpan timeout)
On walking through the implementation of the cache you see that the cache add or removes the tokens and the key is what governs how the tokens are retrieved. In the actual sample the key is is qualified as shown.
Key key = new Key(target.Uri, (issuer == null) ? null : issuer.Uri);
and when the URI is used.
Changes to the Cache to share the Tokens across Multiple Service
Changing the key pretty much increases or changes the total scope of the token. if you changed the key to something like this
Key key = new Key(new Uri(target.Uri.GetLeftPart(UriPartial.Authority)),
(issuer == null) ? null : issuer.Uri);
This pretty much says that the same token can be used across multiple services with the same Authority(usually the domain name in this case).
So there we go we have increased the scope and in this case but you can write your own key building logic and even use something like a predefined list of keys to retrieve the tokens and share them across multiple services.
Check out the source attached and let me know in case you have some queries around this.