Tuesday 5 July 2016

How to Authenticate To SharePoint Online?

 Authentication to SharePoint Online looks really complicated when you look at those multiple redirects in the browser from the time you enter your password till you end up in your SharePoint Page.. Phew..But it is not.. TILL YOU CRACK IT.

SharePoint Online uses Secure Token Service (MSO STS) to authenticate the user. The request with user credentials is posted to STS to validate the user. On validation STS sends the security token as response which is posted to SPO & we receive 2 authentication cookies FedAuth and rtFA.

Federation Authentication (FedAuth) cookie is particular to a particular top level site. The root Federation Authentication (rtFA) cookie is for all top level sites in SharePoint Online. When a user is logged in to a particular site collection and moves to another site collection, the user is silently authenticated using RTFA cookie without prompting the user for credentials. rtFA also enables the user to sign out from all the SharePoint sites when deleted from the application.

.NET Client Object Model authenticates to SharePoint Online using SharePointOnlineCredentials which is part of Microsoft.SharePoint.Client.dll.  I executed the following code in a console application and captured the fiddler network traffic.

static void Main(string[] args)
{
var url = "https://mysite.com/";
 Uri uri = new Uri(url);  
  ClientContext context = new ClientContext(url);  
  SecureString secureStringPass = new SecureString();  
  var myUserName = "MyUserName"  
  var myPassword = "MyPassword";  
  foreach(char p in myPassword.ToCharArray()) secureStringPass.AppendChar(p);  
  var cred = new SharePointOnlineCredentials(myUserName, secureStringPass);  
  context.Credentials = cred;  
  context.ExecuteQuery();  
  var authCookie = cred.GetAuthenticationCookie(uri);  
  Console.WriteLine("cookie = " + authCookie);  
  Console.ReadLine();  
 }  

To Authenticate to SharePoint Online with SSO enabled from applications built on non SharePoint platforms, we can follow the post requests as captured in fiddler for the above console and it goes as below:



  • Step 1
    The first request is made to Home Realm Discovery with the username.This uses, Suffix routing which allows ADFS to select the appropriate claims provider based on the domain suffix provided by the user during logon. Eg: users with mysite.com domain suffix will send authentication requests to mysite identity provider.
          Request
  1.  POST https://login.microsoftonline.com/GetUserRealm.srf HTTP/1.1  
     Content-Type: application/x-www-form-urlencoded  
     Host: login.microsoftonline.com  
     login=myuserName%40mySite.com&xml=1  
    
          Response
           


          STSAuthURL in response provides the URL of the identity provider to which authentication requests are to be posted.
  • Step 2
      Post the following as request body to the STSAuthURL. 

      Request
 <?xml version="1.0" encoding="UTF-8"?>  
 <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wssc="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">  
   <s:Header>  
    <wsa:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>  
    <wsa:To s:mustUnderstand="1">[STSAUTH URL RECEIVED FROM STEP 1]</wsa:To>  
    <wsse:Security>  
      <wsse:UsernameToken wsu:Id="user">  
       <wsse:Username>[myuserid@mysite.com]</wsse:Username>  
       <wsse:Password>[mypassword]</wsse:Password>  
      </wsse:UsernameToken>  
    </wsse:Security>  
   </s:Header>  
   <s:Body>  
    <wst:RequestSecurityToken Id="RST0">  
      <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>  
      <wsp:AppliesTo>  
       <wsa:EndpointReference>  
         <wsa:Address>urn:federation:MicrosoftOnline</wsa:Address>  
       </wsa:EndpointReference>  
      </wsp:AppliesTo>  
      <wst:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType>  
    </wst:RequestSecurityToken>  
   </s:Body>  
 </s:Envelope>  

     Response

     When provided with valid credentials a SAML token with assertion will be provided as response. The assertion is as follows:

 <RequestedSecurityToken>  
     <ns1:Assertion xmlns:ns1="urn:oasis:names:tc:SAML:1.0:assertion">  
       ......  
       .........  
       ..............  
     </ns1:Assertion>  
   </RequestedSecurityToken>  

  • Step 3
     The above response is appended as part of the following request and posted to https://login.microsoftonline.com/RST2.srf

Request

 <?xml version="1.0" encoding="UTF-8"?>  
 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">  
   <S:Header>  
     <wsa:Action S:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>  
     <wsa:To S:mustUnderstand="1">https://login.microsoftonline.com/rst2.srf</wsa:To>  
     <ps:AuthInfo xmlns:ps="http://schemas.microsoft.com/LiveID/SoapServices/v1" Id="PPAuthInfo">  
       <ps:BinaryVersion>5</ps:BinaryVersion>  
       <ps:HostingApp>Managed IDCRL</ps:HostingApp>  
     </ps:AuthInfo>  
     <wsse:Security>  
       <ns1:Assertion xmlns:ns1="urn:oasis:names:tc:SAML:1.0:assertion">  
        ........  
        ..........  
        ............  
       </ns1:Assertion>  
     </wsse:Security>  
   </S:Header>  
   <S:Body>  
     <wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" Id="RST0">  
       <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>  
       <wsp:AppliesTo>  
         <wsa:EndpointReference>  
           <wsa:Address>[Domain Address]</wsa:Address>  
         </wsa:EndpointReference>  
       </wsp:AppliesTo>  
       <wsp:PolicyReference URI="MBI"></wsp:PolicyReference>  
     </wst:RequestSecurityToken>  
   </S:Body>  
 </S:Envelope>  


Response
We will receive a RequestedSecurityToken as part of response from STS as follows:

 <wst:RequestedSecurityToken>  
         <wsse:BinarySecurityToken Id="Compact0">t=EwDwA..........</wsse:BinarySecurityToken>  
 </wst:RequestedSecurityToken>  

Extract the value in BinarySecurityToken tag.

  • Step 4
The value in BinarySecurityToken is posted to SharePoint Online as follows:

Request:

 POST https://mydomain.com/_forms/default.aspx?apr=1&wa=wsignin1.0   
 Content-Type: application/x-www-form-urlencoded; charset=UTF-8   
 t=EwDwA..............  

Response
 In the response headers we receive the authentication cookies  rtFa and FedAuth as response which can be used as part of request header for all further transactions with SharePoint Online.

References:

SharePoint Online remote authentication (and Doc upload)
Remote authentication in SharePoint Online


Tuesday 1 March 2016

Deploying SharePoint Add-in

Developer Site
SharePoint add-ins can be deployed to developer site .This site is used for creating, debugging, testing, and deploying add-ins. Apps developed in Visual Studio 2012/2013 can be deployed directly to developer site without the creation of app-catalog site as shown here .However, any add-in deployed here will not be available in the other site collections for installation.
Developer site can be created as follows:
  1. Login to the Admin center using Global administrator
  2. In SharePoint Admin Center, click on Site collection
  3. Click New - > Private Site collection and select developer site template and provide the required values as input and click on OK.
Add-in Catalog
A private add-in catalog is a dedicated site collection in SharePoint Online tenancy that hosts document libraries for SharePoint Add-ins.
The SharePoint add-in has 2 scopes: web scope and tenant scope. The scope is based on the deployment method.
  • Web scope: When the add-in is uploaded to add-in catalog it is available to be installed on all websites within the tenancy. The add-ins deployed in this manner can be installed in all site collections. However, a user needs read rights on the add-in catalog to be able to see the add-in in "Apps from your organization". This also applies to the list item in the add-in catalog. As a workaround permission inheritance can be broken on the add-in (which is a list item in add-in catalog) and provide permissions to specific users of the required site collection. These users still can install add-ins in other site collections but all users cannot add the add-ins.
  • Tenant scope (app stapling): The tenant admin can specify which websites the add-in is installed to by means of a list of managed paths, a list of site templates, or a list of site collections. By this method, the add-in gets installed to the desired site collections.

But following are the limitations for tenant scope deployment approach:
  • Add-ins deployed using this method cannot be added in add-in-part
  • Add-ins that contain custom action to ribbon cannot be deployed in this manner.
                This will provide more clarity on the same.

Side-Loading
Add-ins can be installed to SharePoint by using App side loading without having to create a developer site or an Add-in catalog. This enables development of apps in site collections which use different template other than developer templateThis requires the global admin to enable side loading feature to be activated. The main reason for blocking side loading by default on non-developer sites is the risk that faulty apps pose to their host web/host site collection. Apps have the potential to destroy data and make sites or, given enough permissions, can even make site collections unusable. Therefore, Add-ins should only be side loaded in dev/test environments and is not recommended to be used in production site. This will provide detailed description for the same

Public Office Store
An app can be made available to other users external to organization (as free and paid packages) by publishing the app to public office store

Following are the steps to deploy to office store:
  • Create and account with Microsoft’s seller dashboard.
  • Microsoft will verify the account and once the account I approved app can be submitted to the app store where it will be validated by Microsoft
  • On approval by the office store team, the app be will available to be installed.
This will provide more details for publishing the apps to app store

Resources:

Use the App Catalog to make custom business apps available for your SharePoint Online environment
Side-loading and developer feature
Apps for Office
Publish apps for Office and SharePoint to the Office Store