I've made my ACS rules generated SWT from idetity provider like facebook and google. Is there a way for an on-line Silverlight application ( NOT OOB ) to process the SWT token and the siging key as parameters in order to retrieve ACS
claims from within the application on the client side ? Where do I pick up the token and the key? How can I unpack the token in silverlight? There is WIF exender example to help extracting SWT on the server side, but is there an example
to address this use case on the Silverlight client side (NOT OOB)?
SWTs are signed with symmetric keys, meaning that the cryptographic data needed to verify a token is the same as the data needed to sign one. If you run code on the client side that has your symmetric key, that is a security risk because your client now
has access to that key and can impersonate you.
We are not looking for an elevated trust app solution. The WP7 you mentioned or the ScriptNotify mechnism were essentially required silverlight app ruunning in elevated trust mode. It looks like I would have to create my own swt token handler and
pass the token to my Silverlight in-browser application instead of deliver it vie ScriptNotify event.....
If you take this approach, you can’t integrate with third party identity providers such as Google and Facebook, as you cannot sign in. However, you can also use server side passive redirection. If the Silverlight application is hosted in IIS, you can use
standard passive redirection mode as you do in ASP.NET, and then you can send the user information to client from server if you like. Refer to
http://msdn.microsoft.com/en-us/identitytrainingcourse_silverlightandidentity_unit for more information.
Thank you! I run the passive WS-federation redirection scenario with ACS, with third party public ID providers like facebook and google associated with my localhost testing relying party . I've done a proof-of-concept example to pass the
SWT to silverlilght upon successful ACS login. The big drawback is that I have to share the signing key with silverlight to do HMACSHA256 signature verification, and has the risk of exposing the symmetry key.
I've visited the unit you mentioned before, will certainly take a look at it again, since SL.identityModel.dll and SL.identityModel.Server.dll do help a lot with client and server side programming. I recall it work against the local STS instead of ACS. Do
I need to make a lot of changes to accommodate ACS? I think the local STS is emitting SAML, would the sample work with SWT? The silverlight app would be hosted in an ASP.NET MVC web application, but the Silverlight binary, the "source" parameter
of the silverlighthost object tag might come from other domains. Would that still work?
ACS is just a kind of STS. So it should work without too much modifications. However, do you have to use SWT? The DPE's SL.identityModel.dll supports SAML. So it would be easier if you use SAML. But I remember the DPE also has an OAuth extension of WIF,
which should help if you use SWT. You can find the OAuth extension in the source code of the Windows Phone tutorial:
http://msdn.microsoft.com/en-us/WAZPlatformTrainingCourse_ACSAndWindowsPhone7. Which domain does the xap come from should not affect this scenario.
If you use passive federation, essentially Silverlight doesn’t take part in authentication. You just need to sign in on the server side. The toolkit created by DPE pointed out in the earlier post should help. Then of course you can send the claims from
server to Silverlight client if you want. But you don’t need to send claims back from client to server, as server already knows the user. So you don’t have to use SL.IdentityModel.dll, and you don’t need to deal with SWT or other kinds of tokens on the client
Marked As Answer byReggie ChenMonday, April 09, 2012 4:07 PM