Make the Xakia sign-in process easy for users by linking to your federated identity service with AD FS.
The Azure Directory Federation Services (AD FS) federated identity option allows you to use Azure Directory Federation Services to sign on to Xakia.
If you want to manage Xakia users from Microsoft Entra, please use this guide to configure Microsoft Entra (Azure AD) Federated Identity with SCIM.
If you want to set up Single Sign-On with Microsoft Entra, please use this guide to configure Microsoft Entra (Azure AD) Federated Identity and Single Sign on (SSO).
The AD FS federated identity option requires an Azure Directory Federation Services system administrator to configure authentication within Azure Directory Federation Services.
Non legal team users should not be added to the group.
Only legal team users should be added to the group. Note that any user added to the group will become a billable Xakia user.
In the event that non legal team members are accidentally added as billable Xakia users, the Xakia support team can help clean this up, however this will attract a service fee.
IMPORTANT: Before configuring AD FS federated identity using the steps below, setting up a Xakia Support Account on your Xakia location is highly recommended to ensure minimal downtime during your switch to AD FS App SCIM federated identity.
Xakia Location Administrator access is required to set up Single-Sign On. Please ensure that the member of IT managing AD FS has a Xakia Location Admin user account setup. This account can be configured without Matter or Contract access and set as non-billable by contacting Xakia Support.
What does Xakia support?
Xakia supports SSO via your organization's AD FS instance. Any version of AD FS that supports the OpenID Connect protocol is supported – AD FS 2016 and AD FS 2019.
If your AD FS deployment is older than 2016 and only supports SAML, we recommend upgrading to a later version of AD FS that supports OpenID Connect. Xakia currently does not support SAML.
How can I set up AD FS?
Setting up federation between your Xakia and AD FS instances requires the following steps below. You will need a Xakia administrator and an AD FS administrator from your organization to complete the setup.
Setting up in Xakia
In Xakia:
Click on 'Admin' in the top navigation menu
Select 'Users & Security' on the left-hand side menu
Select the 'Federated Identity' tab
In the 'Identity Provider' field, select 'AD FS'
Fill in the value of the AD FS URI field (e.g., https://your-org.com/adfs). Your IT administrator will be able to advise the AD FS URI for your organization
Ensure the 'Enable User Provisioning from Xakia' checkbox is checked
Click 'Save'
After saving, the Redirect URI field will populate with a value. Copy this as it will be used below
Leave the Client Id field blank for now, it will be filled in later
Setting up in AD FS
The steps below need to be completed in AD FS. Your IT administrator will be able to complete these steps. Upon completing these steps, your IT administrator will need to advise the Client ID to be entered into Xakia.
In AD FS:
Open the AD FS management tool
Select 'Application Groups' on the left pane and click 'Add Application Group' on the right pane
Enter 'Xakia' as the name
Select 'Web browser accessing a web application' and click 'Next'
Paste the redirect URI value from Xakia above into the Redirect URI field, and click 'Add'
Copy the auto-generated Client Identifier - this will need to be provided in Xakia
Click 'Next'
Configure the access control policy as desired. The policy you use will depend on your organization's requirements. For example, for organizations that use the Internal Client Portal, you may consider permitting all users to sign in
Note: Allowing users to sign in does not affect your billing in Xakia. You are only billed for users explicitly provisioned in Xakia, as outlined below.
Click 'Next', 'Next' and 'Close'
Right-click your newly created Application Group and select 'Properties'
Select the Xakia - Web Application and click 'Edit'
Select the 'Issuance Transform Rules' tab
Add a Rule
Select 'Send LDAP Attributes as Claims' and click 'Next'
Enter a name under 'Claim rule name' e.g., 'Xakia'
Select Active Directory as your Attribute Store
Add the following LDAP Attributes with the following Outgoing Claim Types. Ensure the Outgoing Claim Type is selected from the drop-down list
LDAP Attribute: Given-Name; Outgoing Claim Type: Given Name
LDAP Attribute: Surname; Outgoing Claim Type: Surname
Note: Xakia requires users' email addresses to be used as the UPN. If users' email addresses are always the same as the user's UPN, then no further action is required. However, if users email addresses are different to the UPN in your AD FS configuration, you will need to add a third claims mapping as follows:
LDAP Attribute: E-Mail Addresses; Outgoing Claim Type: UPN
Note: This step is required even if you have Alternative Login ID configured
Finish and close
In Xakia:
Enter the Client Identifier from AD FS in the Client Id field and save
Provisioning users
Users that will sign in with AD FS must be provisioned manually in Xakia.
In the 'Users' tab on the 'Users & Security' menu, use the 'Add User' button to add a user to Xakia
In the form that appears, use the Identity Provider drop-down box to select the AD FS instance that has been configured for your location
The newly added user can then be invited to join Xakia via email and must complete their registration
Once they have completed their registration they will be able to sign in with AD FS
Existing users with Xakia identities can be switched over to use AD FS for authentication in the same way.
In the 'Users' tab on the 'Users & Security' menu, click the 'Edit' button for a user
Use the Identity Provider drop-down box to select the AD FS instance that has been configured for your location
Click 'Save'
The next time this user attempts to sign in to Xakia, they will be redirected to AD FS to authenticate
Changes in user details
If an existing user's first name, last name, or email address changes in AD, note that this change is not immediately propagated to Xakia. This information is only updated in Xakia when the user signs in to Xakia again. In the meantime, Xakia will continue to use the user's old details.
Therefore, when a user's email address changes, they need to use their old email address to sign in to Xakia once. When this is done, their email address in Xakia will be updated to the new value, and from that point on, they can use their new email address to sign in to Xakia.
Consider the following example:
A user exists in AD FS and in Xakia with the email 'old@email.com'
In AD FS, the user's email changes to 'new@email.com'. Xakia still records the email as 'old@email.com' at this point in time
When the user goes to sign in to Xakia, if they use 'new@email.com', Xakia will not recognize their account and they will not be able to log in
The user must use 'old@email.com' in Xakia to sign in first
When they successfully sign in once, their details including their email address will be updated in Xakia. At this point, Xakia now records the user's email as 'new@email.com'
From here on, the user can sign in to Xakia using their new email address: 'new@email.com'
Deactivating users
If a user has left your team and you wish to deactivate their access, a Company or Location Administrator may do so by following these steps:
Navigate to Admin > Users & Security > Users
Select the appropriate Location from the left-hand navigation bar
Find the user on the list you would like to deactivate
Click the 'Deactivate' link beside the user on the right-hand side
Click 'Deactivate User' on the pop-up window to confirm deactivation
Implementation Guide
When implementing and testing federated identity in Xakia, we recommend the following:
Test in your Production Location
Set up a production federated identity provider directly in your Xakia location and use a single test user to verify configuration.
Creating and configuring a federated identity provider in your Xakia location will not disrupt sign-ins for any current users and will not result in any downtime or unavailability in your Xakia location
Existing users will continue to sign in using their Xakia identity as normal while you are testing
Once you have confirmed that your test user can sign in with the federated identity provider as expected, you can complete the implementation for all desired users
Avoid Separate Test Environments
Do NOT create a new Xakia location or use a separate test identity provider. Similarly, avoid using a test IDP tenant or instance. Xakia supports only one federated identity provider per company (with the exception of Microsoft Entra (Sync Job), which supports multiple tenants and locations). Using test locations or IDPs can cause unexpected behavior.
Use a Pilot User
Always test with a real user from your production environment and production IDP to ensure accuracy and avoid complications during rollout (with the exception of Microsoft Entra (Sync Job), which supports multiple tenants and locations).