Cross-Domain single sign-on with azure, ACS, Sharepoint 2010, MVC Site, and WebService

Question

I have a SharePoint 2010 site configured to login with ACS. And ACS configured to use my own Identity provider. I also have a MVC web application which is also claims aware, and uses ACS for authentication. The Idea is to expose certian services from sharepoint, to the MVC site, using the webservice I have build.

Here is a Drawing of the Idea:

My Idea was That once you log in to the MVC site you could use that SAML token(idenity) to log on to SharePoint(i just pass the SAML Token to the web service, and the service attempts to log in to SharePoint with that token). I was hoping since I configured The Relying Parties(MVC site, SharePoint) in ACS to use the same certificate for signing, it would accept the token even if it was from a different realm. But that isn't the case. So I was wondering how my web service could impersonate the user with the claims I have. I've been doing endless Research, and i'm pretty convinced this just isn't possible. The real question is, if there is a way for SharePoint to trust the tokens I get on my MVC site, without building an entire STS and having SharePoint have a trust relation ship with that. Any Help and ideas would be appreciated.

Answer 1

If you are trusting tokens that were created for MVC or SharePoint, then your webservice is part of that "realm" so it is ok to add that realm as a valid one. The audience uri validation can be changed from config or code. Are you using WCF? Are you using WIF with WCF?

<audienceUris>
   <add value="your:sharepoint-and-mvc:realm" />
   <add value="http://webservice" />
</audienceUris>

edit : reading your question again and the clarification you made, you will have issues with SharePoint, since they have an STS that will do some transformations to the original ACS token and sign it again with its own keys. Meaning that you don't have access to the original ACS token. I see two options here:

• Create your own token before consuming the service (you can use SimpleWebTokens or JsonWebTokens which are more simple to implement and a shared symmetric key).
• Configure your service to trust SAML tokens signed by ACS or SharePoint key as well the audience URIs.

Since this is a REST service I would go with option 1, transform the original token to a JSON web token, resign with your own key and attach the token to the Authorization header.

Here you have an implementation of JsonWebTokens (JWT) http://nuget.org/packages/JWT

Here is an implementation of SimpleWebTokens http://nuget.org/packages/netfx-Microsoft.IdentityModel.Swt

You can use JWT also with asymmetric crypto with x509 certs (it is not implemented in that package though)