This article describes how to add Templafy to your current SSO in your Azure AD.
NOTE: Only standard set of claims are supported via this App. Should you want to use the expanded claim set or manage/determine which claims are sent to Templafy, kindly follow this guide instead.
Client IT tasks
- Add Templafy AzureAD app to your Azure tenant by completing the consent flow on this link: https://app.templafy.com/AzureADTenant/
- Provide your tenant ID (Directory ID) to Templafy.
- Provide primary email domain used at login.
- Add client Azure tenant ID and email domain to the configuration
Client IT setup guide
To complete this setup, you need to have credentials as a Global Administrator on your AzureAD.
Click on the Templafy onboarding URL below to initiate the setup:
Next, follow these steps:
1. Go to the onboarding URL, and click 'Sign Up'.
2. Enter credentials of a Global Administrator in AzureAD.
3. Press 'Accept' in the consent dialogue.
4. The app is provisioned in the Azure AD tenant (Enterprise Application).
You have now completed the setup on your side.
Permissions in Azure AD Enterprise Application:
The permissions required in Azure AD for Templafy to work are
- Read directory data (Application Level)
This setting allows us to:
- check if users are deleted in the directory, so we can delete that user (and his/her information) in Templafy
- Update claims and Active Directory Groups for a user without having him/her log login
- Use all Active Directory groups when setting up security in Templafy
- Sign in and read user profile (Delegation Level)
This setting allows us to map and use claims from the user logging in to Templafy
"Delegation" means that we can access data when the users interacts with Templafy
"Application" means that we can access directory data without a user login.
See below screenshots for a full explanation of permissions and consent from within the Azure AD Enterprise Application.
Read directory data:
Sign in and read user profile:
1. If you see the below message, it is an indication that you don't have the necessary rights to complete the consent flow.
2. If the end-user has to sign in each time via your company login screen, then it is an indication that the 'real' single sign on has not been setup by Client IT. The AD must be synced to your AzureAD for SSO to run.