Thursday, September 29, 2016

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.
SAML Authentication with Windows Live ID

References:

Following are the steps to setup Azure ACS.
  1. Create a new Azure AD tenant
Create Azure AD Tenant

Add Directory
  1. Create new namespace
Create new namespace

Azure - create new namespace
Active Directory - Azure
Access Control Namespace

  1. Click Manage to navigate to Azure ACS Management Portal
Azure ACS Management Portal
  1. 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
Azure ACS Identity Providers
  1. 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.
Azure ACS  Relying Party Applications
Azure ACS  Relying Party Applications
  1. Create a rule group for claims-based authentication
Azure ACS  Rule Groups
  1. 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.
Azure ACS  Rule Groups input and output claims
Azure ACS  Edit Rule Group


  1. Map the new Rule group to the replying party application
Azure ACS  Map Rule Group

  1. Click on Add under Certificates and Keys section to configure the X.509 certificate.
Azure ACS Certificates and Keys
Azure ACS Add Token Signing Certificate and Keys
  1. 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
Azure ACS Export Certificates
  1. Upload the certificate and Save
Azure ACS Upload Certificate

Azure ACS Certificate and Keys
Azure ACS Login Page URL
Execute the following line of PowerShell script to create a trusted identity provider and add in to SharePoint.

#the sign in URL can be copied from Application Integration > Login Page Integration

#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

  1. Set Windows Live ID as trusted Identity Provider for the Web Application
Set Windows Live ID as Identity Provider
Set Windows Live ID as Identity Provider
  1. Grant permission to access the Web Application
Grant user permission
  1. Login to the Web Application with live ID.
SAML based Windows Live ID Authentication
SAML based Windows Live ID Authentication Login Page

SAML based Windows Live ID Authentication
SAML based Windows Live ID Authentication User Information
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.
SAML Assertion from Fiddler

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.
Screen shots after adding the sample web part to update the user details.
Register application in Windows App
Get Windows Live ID user information
Get Windows Live ID user information using Live Connect SDK

Monday, September 19, 2016

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.

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.
  1. Build and deploy the solution to a developer site.
  2. When the solution is deployed, open the site and list to which the workflow is added to.
  3. Make entry in the list and submit.
  4. Navigate to the Task list and edit the newly created item to approve the request. (1st level)
  5. Check the Workflow log list to view the status of workflow
  6. Navigate again to the Task list and edit the item to approve (2nd level)
  7. Navigate to the Site Contents page to verify if the subsite is created successfully after approval of workflow
  8. 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
  9. 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