If your organization is using Azure Active Directory (AAD) for single sign-on (SSO), then you should consider connecting Ardoq to your AAD instance. This has plenty of benefits:
- No additional login step required to use Ardoq.
- Leverage the existing security policies for users in your AAD tenant (password policies, required two-factor authentication etc) to keep data in Ardoq secure.
- Seamless user provisioning and life-cycle management.
- Easy user management at scale
- Fine-grained resource sharing with contributors
If this already sounds good to you, then please reach out!
Single sign-on only
The most basic way to leverage AAD in combination with Ardoq is to only use AAD to authenticate the user. If you opt for this alternative you have to send out manual invitations to get users into Ardoq and you have to manually remove them to get them out. Changing roles from e.g. reader to writer also has to been done manually, by an admin. The upside is that you get the get rid of the extra login step for Ardoq users and can rely on the existing security policies in AAD.
User and role management in Azure Active Directory
If you additionally want to manage your Ardoq users from AAD then you have to assign them a role.
This can be done on an individual basis, like in the image above, or you can assign a role to a group. If a user is a member of several groups, or end up having several Ardoq roles assigned to them in some other way, they'll get the most privileged role in the end.
Once a user has been assigned a role, all they have to do to get an Ardoq user is log in. If they already have an Ardoq user it will get re-used if the email is the same in Ardoq and AAD.
If at any point the user is unable to authenticate (e.g. by getting removed from the organization), or if they lose their assigned role, they will no longer be able to access Ardoq.
Hybrid user and role management
It's possible to manage user and roles both in the app itself and in AAD at the same time. This is not recommended, except in e.g. a transitional period to ensure continuity, as it can be hard to get the full picture when you have to take both the in-app assignments and the assignments in AAD into account to get a complete picture.
If there's ever a conflict the role assigned in AAD will win, as the assumption is that this state of affairs will only happen as someone is transitioning to controlling Ardoq from AAD and not vice versa. E.g. Bob might have a role of reader assigned in in AAD, but Alice wants his help on some projects so she elevates his privileges to writer. She now asks Bob to log in to Ardoq and contribute. As Bob logs in the reader role gets propagated from AAD to Ardoq and Bob is no longer able to contribute to Alice's project.
Increasing engagement with the contributor role
The contributor role is a way to get the wider organization to engage with Ardoq in a narrow context.
If a resource is shared to the contributor group then anyone with the contributor role (or higher), and the right link, can interact with that resource, even if they can't access Ardoq in general.
On the permission spectrum this sits somewhere between public (anyone with internet access can view this resource) and member (all Ardoq users in our organization can view this resource) and affords contributions from anyone able to authenticate in the right organizational context, through AAD.