Health Professional & ADFS Integration Guide Martyn Bradshaw, Sitekit Ltd 01/10/2014 09:48:23
Registered Office Company Department Author Document Type Document Title Version Number 1.1 Approved By Sitekit Ltd Sitekit House Broom Place Portree Isle of Skye IV51 9HL Sitekit Ltd Systems Martyn Bradshaw Manual Health Professional & ADFS Integration Guide Chris Eckl Created 15/03/2013 Last Modified 14/11/2017 Status Approved Next Review Date 01/10/2014 Document ID File Name Publisher Rights SKDOC-463-101 Sitekit.Solutions.Systems.Manual.Health-Professional-ADFS-Integration-Guide.SKL.1659.11-2232 2017 Sitekit.Ltd Ltd This document is uncontrolled when Change Log Version & date By Changes Page 2 of 12
Contents 1 Introduction... 4 1.1 Pre-requisites... 4 2 Configuring an ADFS 2.0 Relying Party Trust... 4 2.1 Configuring the Claims Rules... 6 2.2 Allowing ADFS through Threat Management Gateway (TMG)... 9 2.3 Adding the application to ACS in Azure... 9 2.4 Federated login set up in Sitekit CMS... 11 3 Technical Support... 12 Page 3 of 12
1 Introduction This guide explains how to integrate local active directory health professional user accounts with the Sitekit platforms (e.g. Mi Platform, eredbook) using ADFS 2.0.It is designed to be used by IT infrastructure administrators. 1.1 Pre-requisites This guide requires the following pre-requisites to be in place: Configured ADFS 2.0 instance Well-connected Active Directory infrastructure An active directory group containing all health professional accounts granted access to the Sitekit platform It also assumes the Microsoft Threat management Gateway (TMG) software is being used at the network perimeter. 2 Configuring an ADFS 2.0 Relying Party Trust To allow user authentication via ADFS 2.0 to the Sitekit platform, a new relying party trust must be created. This defines which local active directory group is permitted access to the use the trust, where the endpoint is located and what active directory claims are passed in order to allow the authentication to complete. 1. Start the ADFS 2.0 Management tool. 2. Select the Relying Party Trusts node and then select the Add relying Party Trust link from the right hand menu. 3. The Add Relying Party Trust wizard starts. Click start to continue. 4. Paste in the Federation metadata address URL (for Sitekit this is https://sitekit.accesscontrol.windows.net/federationmetadata/2007-06/federationmetadata.xml but may vary depending on the platform you are using e.g. Mi, eredbook etc.) and click Next. Page 4 of 12
5. Enter a suitable display name and any desired notes for this relaying party trust, then click Next. 6. On the Issuance Authorization Rules page select Deny All Users access to this relying party trust, then click Next. 7. On the Ready to Add Trust simply click Next to complete the wizard. You should now have a new Relying Party Trust shown under the Relying Party Trusts node. Page 5 of 12
2.1 Configuring the Claims Rules Next we need to define the claims rules for this relying party trust. 1. Right click your new relying party trust and select Edit Claims Rules. 2. Select the Add Rule button and the Add Transform Claim Rule wizard starts. 3. Click Next to continue. 4. On the configure claim rule page set the following options: Enter a description e.g. Platform (mi, erebook etc) Claims Rules. Select Active Directory in the attribute store drop down list box. Add the following Mapping of LDAP attributes to outgoing claim types: LDAP Attribute Display-Name E-Mail-Address Outgoing Claim Type Name E-Mail-Address Department Role Is-Member-Of-DL Group Page 6 of 12
5. Click Finish to return to the Edit Claims Rules box. 6. Now select the Issuance Authorization Rules tab. 7. You should see an existing rule denying all users. We need to add a rule to permit the active directory group containing your health professional user accounts. 8. Click Add Rule and select Permit or Deny Based on an Incoming Claim then click Next. Page 7 of 12
9. Give the rule a suitable name, select Group SID in the Incoming Claim type list and enter the desired AD group name in the Incoming Claim Value Box. Note, the chosen group must be an AD security group. Ensure Permit access to users with this incoming claim is selected. Then click finish. 10. You will now be returned to the Edit Claims Rules box. Click OK to return to the main ADFS 2.0 window. 11. Right click the Relying Party Trust and select Update from Federated Metadata and then click Update. Page 8 of 12
12. You now need to communicate your ADFS federated metadata URL to sitekit. An example may be: https://youradfsdomain/federationmetadata/2007-06/federationmetadata.xml They will then complete the required configuration within the relevant Sitekit Platform and notify you once complete. 2.2 Allowing ADFS through Threat Management Gateway (TMG) As well as setting up ADFS 2.0 and the associated relying party trusts, access to ADFS must be allowed through your firewall. Many organisations use Microsoft TMG at the network perimeter. The link below explains how to create the required listeners on TMG to support ADFS 2.0: http://social.technet.microsoft.com/wiki/contents/articles/11185.adfs-publishing-rule-in-tmg.aspx You may need to implement slightly different rules based on the firewall in use on your network. 2.3 Adding the application to ACS in Azure Active directory / access control namespaces / sitekit Add a new relying party application to the access control namespace Page 9 of 12
Enter the name, realm (site url) and return url as below (assuming the CMS). Select the appropriate identity provider(s) and rule group(s). Click save at the bottom. Page 10 of 12
Now set the cms / site settings as per the documentation in helpcms.sitekit.net. and below 2.4 Federated login set up in Sitekit CMS In terms of configuration the login and logout are created by embedding magic words :::federatedlogin::: :::federated-logout::: on the relevant templates. Federated authentication is an option for both deployed and hosted systems The site settings are below: 1. Master user group - the master user group that all federate users will belong to. This Page 11 of 12
2. Federation realm - This is the domain the federation server expects the authentication request to come from. 3. Federation metadata XML URL - The main configuration file. Used to define certification and the endpoints below on the ACS federation server 4. Passive URL - read only, updates from the metadata XML filer above on clicking 'install' 5. Signing Entry ID - read only, updates from the metadata XML filer above on clicking 'install' 6. Install button- updates the CMS held endpoints above and stores them locally, update the last refreshed date and time displayed alongside the button. 7. Claims to Sitekit User field name mappings - these are used to provide mappings between what is returned from the claims based authentication and the relevant Sitekit user fields. The following can be set up as an example with all the relevant settings in place in the site settings <a href=":::federated-login:::">federated Login</a><br/> <a href=":::federated-logout:::">federated Logout</a><br/> <p> People ID = :::peopleid:::<br/> Username = :::username:::<br/> Fullname = :::fullname:::<br/> </p> For MS liveid users, whilst the user is authenticated we get nothing back about the specific user, so they just default to 'Federated Anonymous'. For AD Users, we get back full name, email, job, user groups. They are put into the master group that is specified in the Site Settings and as for WIA and web service based authentication they are also added to user groups that have names matching those in Active Directory. 3 Technical Support If you have any problems with this guide or need assistance please contact our support team by emailing support@sitekit.net. Please include your contact details, a brief description of the problem and any error codes or other relevant information. You can also contact us by phone using 0845 299 0900. Page 12 of 12