SSO (Azure Active Directory)

Purpose

SSO allows clients to use an OAuth2 provider (currently limited to Azure Active Directory) to manage user authorization, letting their users log into Digital Fleet using the same flow and credentials as their other managed applications. Once a user has logged in via their OAuth2 provider (AAD), they can access Digital Fleet without any additional authorization flow.

Note on terminology: In DF we use the term “client” to mean “one of our customers”, but in standard OAuth2 terminology Digital Fleet is the OAuth2 “client”. You may see this for example in the AAD Portal, or in external SSO docs, and client admins may confuse these terms during setup. Azure tends to use the term “application” instead of “client” (eg. ApplicationId).

For Clients: Linking AAD Organization to the Digital Fleet Application

Client to provide Digital Fleet their AAD Tenant ID

Each client will also need to link their AAD organization to our DF Application. They will need to have a directory admin authenticate using our SSO login flow, and their auth flow will present them with the option to enable the entire org:

Note that if an admin has not consented for the organization, individual members of the tenant’s directory can individually accept the DF permissions request for themselves (which looks the same, just without the on behalf of your organization checkbox). It is also possible for the admin to individually limit access to the DF app for their users in AAD.

It’s not under our control, but if a client wants to control app permissions at the user level then they’ll need to override the defaults for their DF enterprise app. This is the “Assignment required” switch in the Properties tab.