Prerequisites
Starting point: How to understand what is the number of licenses we need article describes the roles in Allure TestOps. Reading the following explanations implies you read the article on the licences and roles.
General idea
Also,
- You have an external IAM (LDAP, Okta, Google etc.) with 100% of the population
- Most of the users do not require the access to Allure TestOps. If they access the system
- They will consume a licence
- They will be able to make changes in the system
To avoid #2.1 (considering the fact, not everyone need a licence in Allure TestOps) we need
- To assign ROLE_AUDITOR to any user from the external IAM. There is a configuration parameter for instance in the helm chart for that auth.defaultRole
- then, we say all the IAM (OIDC) fellows from auth.oidc.userGroupName must be ROLE_USER
- all the IAM (OIDC) fellows from auth.oidc.adminGroupName must be ROLE_ADMIN
- and we enable the sync auth.oidc.syncRoles for that
What happens when user logs in via external IAM
If the roles sync has been enabled, when an end user uses OIDC or LDAP account for the auth procedure, they first get ROLE_AUDITOR authority as per the rule for a default role assignment (we hope it's done this way).
Then they get additional role accordingly to their group in external IAM, i.e. a fellow from auth.oidc.adminGroupName will have both ROLE_AUDITOR and ROLE_ADMIN assigned, and system always uses the role with higher privileges.
If an end user is not added to any of the said groups, then these users will remain ROLE_AUDITOR and read only access will be granted.
Access to the projects
Both, ROLE_AUDITOR and ROLE_USER users need to be explicitly added to Private projects by a project owner.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article