Azure's ACS service is pretty sweet, and I love all of the magic it can do, but I want a little less magic for my Web app (MVC). If you look at the code samples on CodePlex, it's easy enough to call the service and get a JSON list of login providers from an endpoint like this:
https://.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=http%3a%2f%2flocalhost%3a7070%2f&version=1.0&callback=?
From the resulting JSON, you can render some links to the providers, and once you deal with those logins, they'll bounce you back through ACS, and ACS will do a post with the resulting token to whatever endpoint you set up in the Azure portal.
My question is, what do I do with that token? I don't want to use the WIF "magic" that creates sets an IPrincipal and what not. I just don't want to mess with what I already have in the app.
I wrote a blog post describing a solution for people who want the power of WIF but don't want to convert their entire application to being claim based. This should give you an idea of how you can approach the situation: http://goo.gl/J8WZe
Ultimately, I extended the WIF module classes and added some overrides to replace the magic methods I didn't need.
I have not tested this but the other thing you can do is tap into the WIF workflow by registering for the various events it exposes.
You would do exactly what WIF does with the token. You parse it after decrypting the SAML token. You can see the spec for the SAML token here. I would recommend going with WIF because parsing SAML is not for the faint of heart. You will need to parse out all the claims and then decide what to do with them in your applications. WIF does this by creating the IClaimsPincipal and setting the claims on the IClaimsIdentity.
来源：https://stackoverflow.com/questions/6285158/azure-acs-without-the-generated-code-and-httphandlers