Windows Live ID as an Authentication Provider for SharePoint On Premise

This article discusses the steps that enable the Microsoft Live ID as an authentication provider for SharePoint 2013 On Premise using Microsoft Azure Active Directory

Environment: SharePoint 2013 Enterprise (on premise), Visual Studio 2012, Microsoft Azure

SharePoint does not have a build in option to configure Windows Live ID as Identity Provider, so we need to Setup ACS (Access Control Service) and add Windows Live ID as identity provider. Azure Access Control Service can be used to authenticate your SharePoint 2013 users with Azure AD. In this configuration Azure AD becomes a trusted identity provider for SharePoint 2013.

The following figure shows how authentication works for SharePoint 2013 users in this configuration.

References:

https://technet.microsoft.com/en-in/library/dn635311.aspx

Following are the steps to setup Azure ACS.

1. Create a new Azure AD tenant

2. Create new namespace

3. Click Manage to navigate to Azure ACS Management Portal

4. To add a WS-Federation identity provider to the namespace, Click on Identity Providers link under Trust relationships section, click Add, select Windows Live ID and click Next button

5. To add SharePoint as a relying party application, click on Relying party applications link under Trust relationships section, click Add and provide details about your SharePoint web application.

6. Create a rule group for claims-based authentication

7. Click Add to create a new Rule Group, click Generate and make sure that a rule is created to the group to pass nameidentifier as nameidentifier, as illustrated by the following figure.

8. Map the new Rule group to the replying party application

9. Click on Add under Certificates and Keys section to configure the X.509 certificate.

10. Execute the PowerShell script provided in the Add Token-Signing Certificate or Key page to create a certificate.

MakeCert.exe -r -pe -n "CN=cpazureacs.accesscontrol.windows.net" -sky exchange -ss my -len 2048 -e 09/23/2017

Navigate to MMC > File > Add/Remove Snap-in > select Certificates > click Next > Select My User Account > click Finish to add Certificates in Selected Snap-ins > click Ok.

MMC > Expand Certificates - Current User > Personal > Certificates > select the appropriate namespace > select Export > click Next > select Yes, export the private key > select Personal Information Exchange > click Next > provide password and click Next > Provide Path to export the certificate and click Next > click Finish

11. Upload the certificate and Save

Reference: https://msdn.microsoft.com/en-us/library/gg185932.aspx

Execute the following line of PowerShell script to create a trusted identity provider and add in to SharePoint.

$realm = http://ilinksys121.abc:3333/ #the sign in URL can be copied from Application Integration > Login Page Integration $signinurl=https://cpazureacs.accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=http%3a%2f%2filinksys121.abc%3a3333%2f #Certificate location $certloc = "D:\cpazureacs.cer" $rootcert = Get-PfxCertificate $certloc New-SPTrustedRootAuthority "Windows Azure ACS" -Certificate $rootcert $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc) $NameIdentifier = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn $Email = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming New-SPTrustedIdentityTokenIssuer -Name "Live ID" -Description " Live ID" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $NameIdentifier, $Email, -SignInUrl $signinurl -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" $sts = Get-SPTrustedIdentityTokenIssuer $sts | Set-SPTrustedIdentityTokenIssuer -ImportTrustCertificate $cert

12. Set Windows Live ID as trusted Identity Provider for the Web Application

13. Grant permission to access the Web Application

14. Login to the Web Application with live ID.

Note that the user name is showing some characters and not the user name or email address. This is because the Windows Live ID does not provide user details and send only name identifier in the SAML Assertion/Response. You can check the SAML Assertion sent in the response using Fiddler tool.

In order to get the user name and email address, we can use the Live Connect API. We need to create an ‘application’ on Live Connect and get the client Id of your application. This client Id is used to get the user data with the help of Live SDK.

Following is the URL of the blog post by Martin Laukkanen, which has a sample code and steps that can be used to get the user name and email address of a Live ID user. You can extend the sample as per your requirement.

http://nearbaseline.com/2013/03/sharepoint-and-windows-live-id/

Screen shots after adding the sample web part to update the user details.

SharePoint 2013: Multi-level Approval workflow with custom code activity using Visual Studio 2013

Learn how to use a sequential-style workflow to route a workflow to multiple level depending on the course the workflow takes.

Download Source Code

Summary

Demonstrates how to use a sequential -style workflow to route a workflow to multiple levels depending on the approval status.  It also creates a subsite using a custom activity after approval by all level.

This basic workflow scenario supports a review and approval/reject process. The workflow starts when a list item is submitted. The workflow assigns a task to first level user group, who review the request, makes comments as necessary, and then concludes the task by either approving or rejecting the request. The workflow ends when the request is rejected. Additional tasks are assigned to the second level user group after approval from first level. On rejection, the workflow ends and on approval, a new subsite is created using the custom code activity added in the workflow.

Prerequisites

This sample requires the following:

• SharePoint 2013 installation that is connected to a configured Workflow Manager 1.0 farm.
• Workflow Manager 1.0 that has the March 2013 cumulative update applied.
• Service Bus 1.0, with the Mach 2013 cumulative update applied.
• Visual Studio 2013 and Office Developer Tools for Visual Studio 2013
• Start following services
• Service Bus Gateway
• Service Bus Message Broker
• Workflow Service Backend

Key components of the sample

• CPApprovalWorkflow.sln contains the entire workflow.
• CodeActivityLibrary.csproj contains the solution to add custom workflow activity that is used by the workflow
• The feature folder contains the feature that adds workflow to the list.

Configure and build the sample

Follow these steps to configure the sample.

1. Make sure that you have a site collection created using the Developer Site template.
2. Create two SharePoint user groups named Legal Dept Members and Managers
3. Open the solution Visual Studio 2013.
4. Change the Site URL property on the project to be the URL of the developer site.
5. Build CodeActivityLibrary.csproj and copy the CodeActivityLibrary.dll and AllowedTypes.xml to following locations
1. C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts
2. C:\Program Files\Workflow Manager\1.0\Workflow\WFWebRoot\bin
3. GAC
6. Build ApprovalWorkflowApp.sln.

Run and test the sample

1. Open CPApprovalWorkflow.sln, set the library/list GUID in the Elements.xml file for the list to which the workflow need to be added along with Workflow History List ID and Task List ID.

2. Build and deploy the solution to a developer site.
3. When the solution is deployed, open the site and list to which the workflow is added to.
4. Make entry in the list and submit.
5. Navigate to the Task list and edit the newly created item to approve the request. (1st level)
6. Check the Workflow log list to view the status of workflow
7. Navigate again to the Task list and edit the item to approve (2nd level)
8. Navigate to the Site Contents page to verify if the subsite is created successfully after approval of workflow
9. If there is any change in the CodeActivityLibrary.csproj project, make the changes, move the CodeActivityLibrary.dll and AllowedTypes.xml to following locations, reopen the Visual Studio and add the activity again in the workflow.
1. C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts
2. C:\Program Files\Workflow Manager\1.0\Workflow\WFWebRoot\bin
3. GAC
10. It’s recommended to change the Assembly version each time when there is a change in code activity library to make sure that the latest change is updated.

Troubleshooting

If the workflow fails, it is likely due to following reasons:

1. Prerequisites are not installed properly

2. GUID is not correct

3. User groups are not created

Go to workflow page to check the error message.

Screen shots

New Site Request List (where the Workflow is added to)

Workflow page of New Site Request list. Workflow started after the list form is submitted.

New task has been created and task is assigned to Legal Dept Members group

Edit the task and approve/reject the request.

Workflow History with status logged in.

New Tasks has been created and assigned to Managers group

Edit and approve/reject the request (2nd level)

Workflow History with status logged in.

Subsite created after 2 level of approvals

Download Source Code