Configuring ADFS 2.1 or 3.0 in Windows Server 2012 or 2012 R2 for Nosco Web SSO

Transcription

1 Configuring ADFS 2.1 or 3.0 in Windows Server 2012 or 2012 R2 for Nosco Web SSO Disclaimer and prerequisites The instructions in this document apply to Windows Server 2012 with ADFS 2.1 and Windows Server 2012 R2 with ADFS 3.0. It is assumed that the system has been configured beforehand, and that all relevant software is fully up-to-date. The initial installation and configuration of Windows Server with ADFS is outside the scope of this guide. The screenshots included here were taken on a Windows 2012 test server used while developing the Service Provider endpoint at Nosco, and therefore the URLs used also point to an internal test server they must of course be changed to reflect the real domain name.

2 Share your IdP s federation metadata URL To configure the SSO Service Provider on the Nosco site, we need the federation metadata from your ADFS server. As federation metadata is rarely static, we prefer to have online access to this document. If you re not sure what its URL is, you can find it by opening up the AD FS Management tool, open up Service > Endpoints and finding it in the list under Metadata:

3 Based on the information in the screenshot from the test configuration I ve set up, the full URL is then If, for any reason you cannot grant live online access to federation metadata from outside your organization, you may alternatively download the XML file from your server and mail it to us. If you choose this option and would like to enjoy uninterrupted SSO, make sure that you configure your server to not perform AutoCertificateRollover, or the metadata will be periodically invalidated, breaking SSO logons until we receive the updated metadata.

4 Add Nosco as a Relying Party in ADFS Next up we ll need to add Nosco as a Relying Trust. Expand Trust Relationships, right-click Relying Party Trusts, and select Add Relying Party Trust. In the Add Relying Party Trust Wizard, click Start, make sure Import data about the relying party published online or on a local network is selected, and then enter the federation metadata URL from the Nosco app site in the Federation metadata address (host name or URL) input field.

5 In the screenshot of my example, I ve been using a test site, so the domain name should be changed as appropriate the path is the same, though. Click Next, pick a name for the relying party, click Next, configure Issuance Authorization Rules as per your choosing, then proceed to the end of the wizard and close it.

6

7 Provide user information via claims You need to set up claims to provide the Nosco app with the necessary user information when a user logs in via the IdP. There are a few required attributes, and a few optional attributes that can be sent to the Nosco app to log in a user. Required user data Depending on your setup, the configuration of your IdP may vary. The example given here reflects the test setup described, sending LDAP attributes as claims. Regardless of your setup, the following data is required for a login to be succesful: Name ID: Each message issued by ADFS must contain a unique, unchanging and persistent identifier. What it is, is not important to the Nosco app, just that it s present for every user, that it s unique to the user, that it is the same on subsequent logins, and that it will never change on that user. Given Name and Surname: If you cannot provide these two attributes, you may send a Common Name or Name attribute instead, from which our Service Provider will attempt to extract the user s first and last names. Optional user data How the Nosco app responds to these optional user attributes is configured in the setup section on the site. Please refer to the configuration documentation at the end of this document for details. The address of the user. How the Nosco app reacts on users without addresses depends on how it is configured in the setup section of the site. Group: This tag can be mapped to labels that are configured as public or private, and possibly prefixed with a customizable text. Role: Behaves identical to the Group attribute, using its own discrete settings. Label[:Prefix]: This tag may be used to create custom labels on-the-fly, possibly prefixed. See documentation later for further details. The test setup exemplifies the use of this attribute, prefixed as well as non-prefixed.

8 If you didn t finish the previous wizard opting to edit claim rules, go to Trust Relationships > Relying Party Trusts, right-click the RP you created, and select Edit claim rules. In the Edit Claim Rules window, click Add Rule, and in the Add Transform Claim Rule Wizard, pick Send LDAP Attributes as Claims in the Claim rule template dropdown, and click Next.

9 Name your claim rule, select your attribute store, and then map at least the required attributes as described previously, then click Finish. In my test example (which spans two screenshots to show the entire list) I ve added the following claims, which will be explained in the next section:

10 Click Finish, then OK, and that s basically it. Web SSO can now be enabled on the Nosco site.

11 Explanation of the claims example In addition to the standard simple attributes, my test configuration uses a few advanced attributes. Simple attributes Name ID: I ve used the UPN as the name id as it meets all the criteria of uniqueness and persistence for this identifier. , First Name, and Surname: Please note that Nosco doesn t support multiple addresses. If more than one is sent to us in a token, we ll pick the first one and disregard the rest. Advanced attributes Role: I ve mapped the Title LDAP attribute claim to the Role attribute in the token that will be sent to the Nosco app on successful logins. On the Nosco site, this is configured to become a label used for filtering user lists. Group: Similarly, I ve mapped the Department LDAP attribute claim to the Group attribute, and configured the site to use it in a similar fashion. Label: For exemplary purposes, I ve included the custom automagic Label[:Prefix] attribute in two forms, here used in its simple form; The value sent in this attribute the LDAP Company becomes a label on the user logging in. Label:Lives in: Here, the automagic label attribute is exemplified in its advanced form, with a prefix. As with the simple form, the value sent with this attribute in the example the state or province that the user lives in becomes a label, only here it is prefixed with Lives in, so that it will result in labels such as Lives in New York or Lives in Jutland.