Transition to ADFS authorization and authentication mechanisms as part of a marketing strategy

The article will be interesting to anyone who wants to learn the meaning of the scary term “Active Directory Federation Services” using real life examples, as well as everyone who develops custom systems based on SharePoint and is in the process of deciding which authorization and authentication model to choose, or going to switch an existing solution to ADFS.

And most importantly, it is useful to those who are important consumer qualities of an IT product, its value and convenience for the end user.

Most recently, we have transferred loyalty programs from one of our customers to the ADFS portal. This has become part of a large process of system infrastructure change. It is always more interesting to talk about complex things in relation to the business goals that these complex technical things serve. Therefore - a small description of the loyalty program itself.
')
This is a loyalty system for cashiers who sell the services of our customer. Run on MS SharePoint. Through the portal, cashiers save bonuses and receive gifts for them (souvenirs, tours, gift cards, etc.) The company can thus flexibly manage the sales of the necessary “positions”, analyze the work of cashiers and agencies, and much more useful.

We developed a loyalty program right from the start. The first release took place in February 2013. The development of the system continues. For example, we have just made a complete redesign of the portal. But this was preceded by the migration to ADFS, as the most important stage of modernization. About this - further speech.

In brief, the ADFS operation scheme can be described as:



The client enters the portal, the portal web server redirects the client to the ADFS service for authorization. Here the client passes authorization and receives from the authorization service “CLAIM” (marker), then with the help of this token is authorized on the portal.

ADFS Migration

The loyalty program is part of a complex solution based on SharePoint, which consists of different subsystems that live on different sites. It was necessary to provide Single Sign On to all these products, to simplify and brand the entrance, to make it more familiar to users.

In this case, it was necessary not to create a solution from scratch, but “authorization migration” from “classic ntlm” to ADFS. And we went our own classic way of spent multi-stage preparation for the transfer :

1. We deployed a prototype solution on our test site and began to work out errors.
2. After making sure that everything worked, we compiled the solution deployment documentation and sent it to the customer so that he could deploy the solution to himself.
3. Tested with the customer on a test configuration.
4. Successfully conducted combat migration.

Analyzing your own solution

So, first analyze what we need to go:

1. We have a list of users of the site (several thousand) who need to be replaced with a claim record.
2. We have lists and document libraries with custom permissions. And it is necessary that after the migration of new users the rights remain the same.
3. We have a bunch of custom code (web parts, pages, handlers, etc.) that check the level of user access through AD. All this needs to be refactored and rewritten, given the fact that users may be branded.
4. Since we are switching to ADFS not the entire portal, but only a single node, we will have to allocate the node into a separate web application. But part of the data is used from the root node, so it is necessary to take out the data manipulation layer in the WCF service, with which we will receive this data in our new application.

We begin the process:

1. We started with 4 points - highlighting the receipt of data from the root node into a separate service and the subsequent separation of our node into a separate application.
   
   In the first part, there were no special problems - an ordinary code refactoring and setting up a WCF service. A couple of weeks - and everything works.
   Separating a node into a separate application poses some difficulties. Basically, they were connected with the fact that during import / export it was necessary to make sure that all the data was saved, users dragged, rights remained. But since there was a lot of data on the node, the import / export procedure took about 3 hours, and if the result was unsuccessful, the whole thing had to be restarted and re-started again.
   
   The longest and most incomprehensible problem until some time was the problem with the import of users. They seemed to be imported normally, but the rights to the lists and the libraries and fields with the User type did not want to be restored.
   
   After a long and painful search for the reasons, it turned out that the problem was that the portal had previously been migrated from SharePoint 2007 to SharePoint 2010, and in the list schema, the description of the User field was incomplete. I had to start to run the utility (written by myself), then again do the export / import. After that, the import was successful.
2. Now you can switch the new application to ADFS. We follow the standard procedure:
   
   a. Install the trusted ADFS server and certificate via powershell script
   
   

   $map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $map2 = New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming $map3 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UserPrincipalName" -SameAsIncoming $signingTokenCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$signingTokenCertPath") $webServerCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$webServerCertPath") $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS Federated Server" -Description "ADFS Federated Server" -Realm $realm -ImportTrustCertificate $signingTokenCert -ClaimsMappings $map1,$map2,$map3 -SignInUrl $signinurl -IdentifierClaim $map3.InputClaimType New-SPTrustedRootAuthority "ADFS Token Signing" -Certificate $signingTokenCert New-SPTrustedRootAuthority "ADFS web server" -Certificate $webServerCert 

   
   
   b. Change application authentication settings
   
   
   
   c. We migrate users in order for all permissions to become through Claims (again through the powershell script)
   
   

    $webAppUrl = "..." $account = "..." $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString() $webApp = get-SPWebApplication $webAppUrl $policy = $webApp.ZonePolicies("Default").Add($account,"PSPolicy") $fullControlRole=$webApp.PolicyRoles.GetSpecialRole("FullControl") $policy.PolicyRoleBindings.Add($fullControlRole) $webApp.Update() $webApp.MigrateUsers($true) $webApp.ProvisionGlobally() 

   
   
   d. After that, we update all existing accounts and bring them to Claim records of the form i: 0e.t | ADFS Federated Server | user @ company
   After that, everything worked as a whole. Then they trained for a long time locally and on test servers.

Fighting Switching and Problems

Combat switching was done on Saturday, since the time for export / import only took about 5 hours. In the end, with all the minor problems started at 9 am, finished at 12 at night :)

In general, everything worked right away, since before that everyone had been trained and tested on a test environment. But one bug got out, which on the test we have never repeated (and still does not repeat) - the problem of logout in Internet Explorer.

The bottom line is as follows:

To exit, use a redirect to an ADFS server page like adfs.ru/adfs/ls/?wa=wsignout1.0&Source=yoursiteurl

When a page is requested, the server handler deletes the session from ADFS, and in order to delete the authorization cookies and the session in SharePoint, on the same page lies an invisible iframe in which the exit page of the SharePoint portal is loaded.

So, in order to log out to SharePoint correctly, you need to pass the FedAuth authorization cookies in the request when calling this exit page.

As it turned out, this is not always the case in IE, and the effect was obtained when we click on the exit, but we cannot exit.

As a result, I had to tweak the exit url a little, so that after working on the ADFS logout page, the SharePoint logout page was called directly and after that the ADFS authorization page was called back:

https://myadfs.ru/adfs/ls/?wa=wsignout1.0&Source=https%3a%2f%2fmysharepoint%2f_trust%2f%3fwa%3dwsignoutcleanup1.0%26wreply%3dhttps%3a%2f%2fmyadfs.ru
(this is provided by MS out of the box).

Conclusion

Why was the loyalty program migration to ADFS important for the customer?

1. ADFS allows you to log in to the portal using a friendly login password instead of the awesome standard Windows Authentication form. Also, if the user has forgotten the password, the system will kindly prompt him, you will not need to look for the admin and prove to him that you are not a camel.
2. Such an entry can be branded with corporate colors and symbols and tailored to uniform corporate visual standards.
3. ADFS makes it possible to configure single sign on authorization, and users will not be able to generate accounts, but log in using their accounts in social networks. What can not but affect their mental equilibrium and positive attitude to work :)
4. ADFS is great for use in such complex systems as our customer, because provides single sign-on functionality to different web applications during one session.