Here you can find instructions how to configure Trivore Identity Service TrivoreID authentication to work with Azure AD. Configuring Azure AD itself is out scope of this document (only general requirements provided here).
This configuration makes it possible to use existing Azure AD instance to sign-in to Trivore ID.
Configure Trivore
...
ID
First, select User directoriesDirectories from main menu as shown below and click button Add directory.
...
You will be asked to select directory type. Select Azure AD.
...
...
Core settings
Configure necessary settings, including Name, Tenant, Client ID and Client secret. Depending on your use-case, you may also need to adjust Scope value. Default Scope value provides Trivore ID access to basic user information on Azure AD, and is sufficient for most use-cases.
...
Appropriate values for Tenant, Client ID and Client secret all depend on the service provider (the organisation managing the Azure AD instance you are integrating to). Azure AD needs to be configured first before these values are available.
After you have configured necessary settings, you may need to adjust attribute mappings. Default mappings are suitable for most cases. See below.
...
All fields are documented in detail in table below.
...
Field
...
Description
...
Default value
...
Example value from Azure AD
...
Allow creating new users
...
Allow or deny creating new users. If you want to allow every user from Azure to sign in to Trivore Identity Service, you need to check this. If not checked, only existing users can link their accounts with Azure AD accounts
...
False (not checked)
...
N/A
...
Link ID
...
Permanent, non-secretive user identifier from Azure AD. Rarely needs to be modified.
...
sub
...
“kk-N8_WZKfkIi6g_gkm5dyWW6coqSwZPLMfIzWYVeoI”
...
Username import policy
...
How to handle usernames in Trivore Identity Service. This option exist in order to guarantee username uniqueness within namespace, which is a technical requirement. You can choose to import usernames from Azure but preferred method is to generate them automatically using default settings.
...
Automatic namespace username policy (actual value depends on the configured policy in namespace settings)
...
N/A
...
Update username if it does match given settings
...
Update user’s username on every successful login if it does not match given settings. Very rarely needed feature
...
False (not checked)
...
N/A
...
Friendly name
...
Friendly name for user’s Azure AD account that helps s/he identify it. Only useful if users are given access to manage their account linkings (add, edit, remove links)
...
name
...
“John Doe”
...
First name
...
Attribute from Azure AD that provides user’s first name
...
given_name (OIDC standard attribute)
...
“John“
...
Last name
...
Attribute from Azure AD that provides user’s last name
...
family_name (OIDC standard attribute)
...
“Doe“
...
Full name
...
Attribute from Azure AD that provides user’s full name, including both first and last name and possible middle names. This is only useful if separate attributes for first and last name are not available.
...
name
...
“John Doe“
...
...
Attribute from Azure AD that provides user’s email
...
...
“john.doe@example.com“
...
Email verified
...
Attribute from Azure AD that provides user’s email verification information. Boolean attribute. May not be available
...
None
...
true
...
Mobile
...
Attribute from Azure AD that provides user’s mobile number
...
None
...
+358401234567
...
Mobile verified
...
Attribute from Azure AD that provides user’s mobile number verification information. Boolean attribute. May not be available
...
You will need the Redirect URL (shown in picture) value when configuring Azure AD. Note that this value is different for every Trivore ID instance.
Field | Description |
|---|---|
Name | Any name you want to choose for this directory. |
Tenant | Azure AD instance unique identifier. |
Domain hint | Login domain hint. This field can be used to auto redirect user to on-premises ADFS if all users belong to a domain that should use it. refer to Microsoft documentation for more information. |
Client ID | OpenID Connect |
Client secret | OpenID Connect |
Scope | Adjust scope if needed. Scope defines what user information/attributes can be imported. Refer to Microsoft documentation for more information about appropriate Scope values. |
Attribute names to fetch from GraphAPI (extra values) | Fetch these user attributes from GraphAPI on sign-in. This field is needed only on special cases where you have defined dot-separated mapping like “ |
User information
After you have configured necessary core settings, you may need to adjust user attribute mappings. Default mappings are suitable for most cases.
...
Azure AD uses common user attribute mappings documented at Common user directory settings.
Field | Description | Default value |
|---|---|---|
Import user’s photo | Import user’s profile photo from Azure AD. | True (checked) |
Group information
Azure AD uses common group attribute mappings, with some additions.
...
Below is table that describes Azure AD specific fields for group information.
Field | Description | Default value |
|---|---|---|
Import security enabled groups only | Import only security enabled groups from Azure AD (GraphAPI). For more information, see https://docs.microsoft.com/en-us/graph/api/resources/groups-overview?view=graph-rest-1.0 | False (not checked) |
Select which group memberships to be imported | It is possible to import either direct group memberships only or all group memberships, including transitive memberships (ie. membership via another nested group) | Import all group memberships, including transitive memberships |