Kept AR in the back burner for some time to focus on an mobile app solution. Was kind of surprised that’s there was not much help available on the net for the scenario I was facing. Was even more surprised that Microsoft support did not help much; we raised a ticket and had discussions for over a month but to no avail. Issue with this, was that there were multiple technologies in the mix – SharePoint, ADFS, WAP, mobile access, Kerberos , WebAPI and the support calls kept putting in experts in each field but no one who could look at all of it together and give a solution. Finally came up with a workable solution, and just detailing it out in case it helps anyone out there with the similar sort of setup and requirements.
So the scenario is simple enough, we had a SharePoint 2013 environment running in-premises with Windows authentication (claims of-course) and things were going on fine, when people realized that they needed to enable it for mobile access from outside without going through the VPN. To achieve this Microsoft provides ADFS and the ADFS proxy (WAP). Simple enough according to the documentation; however there is one aspect that is not highlighted enough in the documentation. You can’t just point ADFS to a windows authenticated site, you would need to enable ADFS authentication in SharePoint.
Now the problem. If the Windows authenticated SharePoint site is converted to ADFS authentication, it does not automatically map the Windows authenticated user with the ADFS authenticated user. Reason pretty obvious, if you go through the info here https://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-20102013-claims-encoding.aspx. So when Chris Nolan logs in using Windows claim, SharePoint understands him as i:0#.w|contoso\chris.nolan, where as if he logs in after SharePoint is moved to ADFS authentication he would be understood as i:firstname.lastname@example.org.
Now there are two ways around this. One is after moving to ADFS, convert all the user info stored in each and every site in SharePoint from the windows claim to the ADFS claim using powershell scripts. This is provided in the User Migration script here https://blogs.msdn.microsoft.com/sambetts/2014/09/03/how-to-migrate-sharepoint-users-to-adfs/ .
One common solution is to cover all the use tokens to the ADFS format over a weekend of downtime as documented here https://blogs.msdn.microsoft.com/sambetts/2014/09/03/how-to-migrate-sharepoint-users-to-adfs, however when you have loads of content and all sorts of customization on a SharePoint environment that’s being used on a daily basis, it’s an administrative nightmare. The other solution that we finally went ahead with is to convert the NTLM authentication to Kerberos and then have ADFS to issue Kerberos tokens.
With that solution we were able to get the whole thing up and running pretty quickly with minimal disturbance to the existing environment.
Once we got that done and people were able to access the sites from outside the network, the natural next request came.. to have a mobile app that accessed some of the info from the site. We went through multiple iterations on trying to convince the usage of the responsive site rather than an app, however all the requirements were those that needed and app.. offline storage, not having to have to login everytime it is accessed, speed etc. Etc.
We decided to go with the ADFS for authentication with OAuth which is supported with the windows 2012 R2 version. The idea was that OAuth would be used to authenticate a person in ADFS and then the Saml token created by ADFS would be used to then generate the Kerberos token and once that is done, making a call to SharePoint would work. However this did not seem to happen and even after going through Microsoft support was not able to get much insights as to why this was not working or even if this actually was a supported scenario.
Since there was not much progress on this for quite a while and the business was getting impatient, I came up with a solution that although not sure the best one for our scenario, did work well.
The idea was to have a ‘proxy’ layer which would be a WebAPI protected by ADFS, which would be called by the mobile app using oAuth. Now in the proxy we would understand who the user is and then making use of server side coding fetch data from the site by impersonating that user. Now this scenario is not ideal if you would have a wide variety of things to access from SharePoint, however for the mobile app all the data we needed was structured in the same fashion so we did not have to write too many proxies , rather just have a generic one that accessed data from all over.
Faced quite a few challenge along the way however once this approach was decided on, we were able to proceed with the development pretty quickly.