As a part of your Enterprise plan, you have access to domain-secured single sign-on (SSO), for example, using Active Directory Federation Services (ADFS) via SAML v2. 

To set up SSO, please contact us at support@wisetime.com.

Setting up Single Sign-On using Active Directory

To make use of ADFS as your authentication mechanism to WiseTime, you need the following:

• A server running Microsoft Server 2012 or newer with an Active Directory instance, or an Azure AD, where all users have an email address attribute set; and
• A WiseTime account on the Enterprise plan.

Please note:

If you are using Active Directory, you will need to install ADFS on your AD server. Installing and configuring ADFS is beyond the scope of this guide, but is detailed in a Microsoft KB article.

Windows Server 2012 R2 ADFS configuration

Step 1 - Add a Relying Party Trust.

1. Select the Relying Party Trusts folder from ADFS Management, and add a new Standard Relying Party Trust from the Actions sidebar. This starts the configuration wizard for a new trust:
   
   
   
   
2. Create Relying Party Trust from the metadata XML or URL provided to you by the WiseTime team:
   
   
3. Click “Next” and accept all default values until Finish and “Close”.
   
   Well Done! Your Relying Party Trust is now created.

 Step 2 - Create claim rules

1. You can now create the necessary claim rules. You will need to create 3 rules:
   
   
   
   
2. The template for the first rule is Send LDAP Attributes as Claims:
   
   
   
   Recommended name: ”Send Attributes (Email, First Name, Last Name)”
   
   Map the email address, first name, and last name:
   
   
   
   
3. The template for the second rule is Send Claims Using a Custom Rule.
   
   
   
   Recommended name: ”Add Persistent Claim”
   
   This will create a random persistent UUID for every user with the account name as seed.

   Copy the below text to the “Custom Rule” field:

   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
   
    => add(store = "_OpaqueIdStore", types = ("https://wisetime.com/persistentId"), query = "{0};{1};{2}", param = "ppid", param = c.Value, param = c.OriginalIssuer);

   
   
   

4. The template for the third rule is again Send Claims Using a Custom Rule (see above).
   
   Recommended name: ”Transform Name ID”. 
   
   This will transform the created persistent UUID into a persistent NameId assertion: 

   Copy the below text to the “Custom Rule” field:

   c:[Type == "https://wisetime.com/persistentId"]
   
    => 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:persistent", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "");

   
   
   
5. Verify the order of rules is as follows (if not, arrange the order accordingly):
   
   
   
   

Provide SAML configuration to WiseTime Team

Windows Server 2012 R2

After you have finished setting up the AD SAML connector, please forward the information about your AD instance to WiseTime team. To do so, please send AD FS metadata URL (usually https://<your_adfs_server>/FederationMetadata/2007-06/FederationMetadata.xml), or if you are not able to share the above link, download the FederationMetadata.xml and send it to the WiseTime team to conclude the SAML authentication setup.

Azure AD

You can copy the link or download the SAML metadata XML from the Application settings in the Azure Portal (section Single sign-on). Check https://docs.microsoft.com/en-us/azure/active-directory/develop/azure-ad-federation-metadata for more information.