When working with Silverlight, we often end up communicating with some form of services. They might be SOAP-based WCF services, which Silverlight handles fine, but lately REST-like services have become a lot more popular, and Silverlight doesn’t always handle them as nicely… They often rely on headers and HTTP verbs other than GET and POST, which Silverlight doesn’t handle very well by default. In my world, I am currently spending a lot of time working with a Silverlight client that is used in a situation where we use federated security. This requires the client to carry around a token that tells the service who he/she is, and what claims are being made. In this case, we are using the thinktecture IdentityServer, which after a bit of configuration works very well. It makes it very easy to integrate with using Silverlight, which is nice. All you need to do is do is to make an HTTP GET call to the identity server, passing along the credentials in the form of a basic authentication header. The identity server in turn replies with a token that identifies the client (at least if the credentials are valid). The client can then POST that token to the the service (relying party) who will then use that token to authenticate the client. And after that, everyone is happy, and the service can trust the client being who he/she says he/she is… So in theory, this all just works, no problems at all. And to be honest, it pretty much does! The actual “session”, and by session I mean the period when the service trusts the client, is limited by the token and kept alive using a cookie. What this means, is that the service puts the token in a cookie which is passed back and forth to the server with every request. The token in turn contains a date and time that defines when it is no longer valid. So all the server has to do is to look at that token every request, and make sure it is still valid… Read more: DarksideCookie
QR:
QR:
Posts
0 comments:
Post a Comment