This guide is for IT Administrators to setup ADFS for integration with Lucidity Software Products
Table of Contents
A Quick Overview of what you get from ADFS
To help understand what benefits are achieved by setting up ADFS, the following summary has been prepared so you can see the difference between an ADFS authenticated system and normal authentication.
Normal Authentication
- User opens login screen and enters Username and Password. There is a password reset option.
- Lucidity authenticates against the Username and Password that has been stored within Lucidity Access. If this authentication fails the user is unable to log in.
ADFS Authentication
- User is presented with a login screen for ADFS that allows them to proceed with an ADFS login ('login' button) or switch to non-domain login if they are accessing the system from outside the company network.
- Option 1 - User clicks 'Login' button.
- Scenario A - User is logged onto the network domain.
- Lucidity obtains the current username 'from the browser' that the user used to authenticate against the network domain.
- If that username has a corresponding entry in Lucidity Access with appropriate permissions to allow entry into the application, then entry is allowed.
- If the username that was used to log onto the network domain does not have a corresponding entry in Lucidity Access, then entry is not allowed.
- Scenario B - User is NOT logged onto the network domain, but still wishes to use domain credentials.
- An ADFS login dialog is presented, asking for domain login credentials.
- User enters Username and Password which are authenticated against the domain.
- If the Username and Password match a domain account AND there is an account in Lucidity Access with the same Username and appropriate permissions, entry is allowed.
- An ADFS login dialog is presented, asking for domain login credentials.
- In the instance where entry is not possible using ADFS, the user can still revert to non-domain credentials (see Option 2).
- Scenario A - User is logged onto the network domain.
- Option 2 - User clicks 'Login with non-domain credentials' button.
- User is presented with a login screen which requires entry of a Username and Password. User enters these details.
- Lucidity authenticates against the Username and Password that has been created within Lucidity Access. If this authentication fails the user is unable to log in.
- Note that the username and password must be those recorded in Lucidity Access, as this is a non-domain login.
- User has the option of reverting the to ADFS login if they separately log onto the network and return to the browser to re-attempt authentication.
- User is presented with a login screen which requires entry of a Username and Password. User enters these details.
...
Info | ||
---|---|---|
| ||
The user must be authenticated against the local network domain in order for ADFS to function. The user must have the same username within Active Directly and Lucidity Access so that Lucidity can determine what permissions to give the user when they log in using ADFS. Lucidity still includes a non-domain login option for times when the user wishes to access Lucidity but they are not logged onto the network. |
ADFS Setup
Term | Description |
---|---|
IdP | Identity Provider, acts as identifying party in federation requests |
SP | Service Provider, acts as consumer of relayed information in federation requests |
Relying Party | Microsoft's terminology for SP |
idp-instance-url | Web-accessible path to ADFS IdP instance. Must be accessible via HTTPS |
...
Widget Connector url https://www.youtube.com/watch?v=fwHIKlAPV0g
1. Install AD CS (IdP)
Active Directory Certificate Service is required to sign requests made by IIS when authenticating ADFS.
Following instructions in the below video, install ADCS, and create a Certificate Authority for the machine. This will be used to issue certificates later in the process.
Follow instructions between 0:50 to 5:40
2. Create a certificate used to sign requests (IdP)
Following instructions from 5:40, create a domain name. Enter the idp-instance-url (e.g. adfs.yourdomain.com) into the 'Common name' and 'Friendly name' field. The certificate must be issued against the URL that will be used to perform the authentication requests.
3. Install AD DS (IdP)
Using the Server Roles, install AD DS. Create a test user that will be used later on to test authentication. Ensure the User has username, password, email address and name specified.
4. Install ADFS (IdP)
Following instructions from 12:00, install ADFS. Install via the AdfsSetup.exe (as shown in the video) which is available for download from http://www.microsoft.com/en-us/download/details.aspx?id=10909. Installing ADFS via the Server Roles screen causes issues where federation metadata not being installed correctly.
Follow the configuration guide in the video, ensuring to that the idp-instance-url matches the friendly name.
5. Send URL
Send the url that will be used to authenticate requests to your contact at Lucidity Software. Once setup is complete at our end we will send you a url to be used in the next step
6. Add Relying Party (IdP)
On the ADFS machine, go to the url provided in the previous step in Internet Explorer (url will look like https://simplesamlphp-url/simplesaml/module.php/core/frontpage_federation.php)
Info | ||
---|---|---|
| ||
When testing: If you receive a certificate error, view the certificate, and then install the certificate to the Trusted Root Authority store. |
7. Copy Metadata
Copy the Entity ID URL under the SAML 2.0 SP Metadata section (that matches the authsource configured in the above step) from the URL https://simplesamlphp-url/simplesaml/module.php/core/frontpage_federation.php.
...
Click 'Next' through remaining steps in Relying Party wizard
8. Configure Claims Rules (IdP)
In ADFS console, right-click on the Relying Party created in the above step, and select 'Edit Claim Rules'.
...
Configure an LDAP Claim
Code Block c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"), query = ";mail,userPrincipalName,displayName;{0}", param = c.Value);
Configure Outbound LDAP attributes to be sent. As a minimum, email, UPN and Given Name
9. Create Unique Identifier
- Create a Custom Rule
Create Custom Rule
Code Block language none c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] && c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant"] => add(store = "_OpaqueIdStore", types = ("http://mycompany/internal/sessionid"), query = "{0};{1};{2};{3};{4}", param = "useEntropy", param = c1.Value, param = c1.OriginalIssuer, param = "", param = c2.Value);
NB: the URL http://mycompany/internal/sessionid should be written as is, and not substituted.
10. Create Incoming Transform
- Create an Incoming Mapping
- Using the custom rule created above, make an incoming mapping
NB: the URL http://mycompany/internal/sessionid should be written as is, and not substituted.Code Block c:[Type == "http://mycompany/internal/sessionid"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient");
11 Test Authentication via simplesaml (SP)
Navigate to https://simplesamlphp-url/simplesaml/module.php/core/authenticate.php, and click on the appropriate auth source.
...