2

The scenario:

  • Our current stack is a SharePoint 2013 web application
  • Users log in to the SP2013 using ADFS claim-based federated authentication: When users click "Log In" in the SP site, they are redirected via ADFS to the identity provider that authenticates the user and using SPs built in support for federated authentication we get a SAML token that is stored in SharePoints Secure Token service. The user's browser get a FedAuth cookie that (if I understand correctly) refer to the token stored in SharePoint.
  • We want to gradually migrate away from SP to a ASP.NET MVC-based stack
  • The key here is gradually migration: We want to migrate pages and REST services from SP to a new system piece by piece.

For instance, URL /thisurl/ should be handled by the legacy SP application, and /migratedurl/ should be handled by the new ASP.NET MVC application.

I have the following questions/issues:

  • Question 1: How do we handle authentication in the new setup? I imagine the authentication (i.e. handling the user clicking the "Login" link, redirecting to ADFS -> identity provider) will still be handled by the legacy SP site. In this scenario, how can the new ASP.NET MVC application access the claims for the authenticated user?
  • Question 2: What is the best way to deploy this? Should the new ASP.NET MVC application be a IIS web app under the SharePoint web site? Or should it be a new IIS web site? Keep in mind that ASP.NET MVC app needs to do AJAX calls to the SP site and vice versa.

My understanding of SharePoint, federated identity, ADFS etc. is at best limited, so my description of our system might be lacking, there might be things that I misunderstand, there might be terminology that I don't get right etc. Please let me know if there are changes I can make to the question to make it clearer.

codeape
  • 97,830
  • 24
  • 159
  • 188
  • Your URL examples above indicate that SharePoint and MVC stack will be hosted on same domain e.g. https://yourdomain.com/thisurl/ and https://yourdomain.com/migratedurl/ - Is this correct? – Salman Siddiqui Apr 21 '16 at 20:33

2 Answers2

2

What you have in ADFS terms is two separate Relying Party (RP) viz. the SP site and the new MVC application.

ADFS applies SSO across them.

Your new app. will be claims-based i.e. you need to add WS-Fed functionality via WIF (older) or OWIN (new and shiny).

Refer: Use the OWIN Security Components in ASP.NET to Implement Web Sign On with ADFS for a good OWIN / ADFS example.

So what happens is that a user logs in to SP. They now have both SP and ADFS sets of cookies. They now log in to the MVC app. They have no app. cookies so they are redirected to ADFS. ADFS / OWIN sees they have ADFS cookies so creates app. cookies and the user is seamlessly signed in.

The cleanest deployment method would be to make the app. a new IIS web site.

This has two advantages:

  • No dependencies on SP
  • Very easy to migrate to Azure in the future (just needs some web.config changes)
rbrayb
  • 46,440
  • 34
  • 114
  • 174
  • OK. Just to be clear: This would require that the first request to the MVC app is a normal page load? To get the redirect flow - cookie creation going? If the first request to the MVC app was a AJAX call it would not work, right? (since the browser's XHR object will not take part in the authentication redirect process?) – codeape Apr 22 '16 at 08:05
  • The first call can be anything but the moment you hit a protected page, you will be redirected to ADFS. WS-Fed and SAML do not use Ajax it's all normal browser redirects. Also note that the tokens that SP and the app get are different because ADFS would have different claims rules for each. In terms of getting the claims, see Step 3 - https://msdn.microsoft.com/en-us/library/hh291061(v=vs.110).aspx – rbrayb Apr 25 '16 at 18:37
1

If the answer to my question in comments is a 'yes' then your MVC stack should be able to access the FedAuth cookie and query the federated site for a new token.

This implies that that the MVC stack would be hosted below SharePoint on same level in IIS. This is the answer to your Q2 I think :)

Please see Sample Federation, delegation and authentication scenarios in SharePoint 2013

specifically the Federated scenario;

  1. A client in the Fabrikam trust domain sends a request to a relying party application in the Contoso trust domain.

  2. The relying party redirects the client to an STS in the Contoso trust domain. This STS has no knowledge of the client.

  3. The Contoso STS redirects the client to an STS in the Fabrikam trust domain, with which the Contoso trust domain has a trust relationship.

  4. The Fabrikam STS verifies the client's identity and issues a security token to the Contoso STS.

  5. The Contoso STS uses the Fabrikam token to create its own token, which it sends to the relying party.

  6. The relying party extracts the client's claims from the security token and makes an authentication decision.

Salman Siddiqui
  • 340
  • 3
  • 13
  • OK but what could my MVC app do with the FedAuth cookie? If I understand correctly, the FedAuth cookie contains an id of the token that is stored in SP Secure Token Cache. How can the MVC app use the FedAuth cookie to get the authenticated user's ID claims? – codeape Apr 22 '16 at 08:02
  • @codeape I think your MVC application is the relying party in above description. The token should contain pass/fail message. If the user was successfully authenticated, your application then gives them appropriate access based on prior definition of access. That's what I am reading in step 6 above. YMMV etc. after all, its Microsoft. The biggest purveyor of vaporware in the World :) – Salman Siddiqui Apr 26 '16 at 18:39