Yes! Just set up both - LDAP and SSO. In such configuration users will be authenticated with SSO and authorized based on LDAP groups membership.
To achieve that:
On Single sign-on configuration, disable "Assign users to groups based on SAML 2.0 response attribute" option.
On User groups, configure matching of group name and LDAP group name.
Hope this helps!
It's not entirely like that.
If you set user repository to LDAP and enable SSO to SAML protocol then you have still 2 log-in options:
1. Standard (Dynatrace log-in form)
In that case, authentication (users source) is retrieved from LDAP; authorization (groups / permissions) are retrieved also from LDAP.
2. Log-in via SSO (redirect to SSO)
In that case, user is redirected to the configured Identity Provider (IdP) - SSO. User authenticates there and IdP returns groups membership. And now:
a) If switcher "Assign users to groups based on SAML 2.0 response attribute" is turned on
then authorization (groups / permissions) is taken from SSO.
b) If switcher "Assign users to groups based on SAML 2.0 response attribute" is turned off
then authorization (groups / permissions) is taken from LDAP.
So in all cases (with or without SSO), when you select LDAP -> local users are ignored - as a user query goes to LDAP. If that "local user" doesn't exist in LDAP, you get unauthenticated response.
If you want to retain local users and have SSO available - turn off LDAP.
Only "admin" user is able to log-in in any mode.
Thank you. If I turn off LDAP and enable SAML with Standard (local users) + SSO activated, do the SAML user inherit the rights and permissions form the local user, if e.g. the username of the SAML user and the local user is the same?
This is the usecase: user orders access via a self-service portal. The portal creates a local user via Dynatrace API. Then the user logs in via SAML and ... does he inherits the rights and permissions form his local user providing that the username is the same?
Hope my question makes sense 🙂
So then that depends where do you want to keep permissions management. You have 3 options:
1) Local, in-Dynatrace - In that case you have to maintain user-group mapping in Dynatrace. Using REST API for instance.
2) LDAP - you need to have groups granularity in LDAP that matches groups in Dynatrace and maintain this in both LDAP and Dynatrace. If you turn off LDAP you switch to local. All user-group mappings that were created via LDAP should be maintained - so you don't need to start from scratch. But revisit of user-groups mapping is recommended.
3) SSO / SAML - If you have importing groups from SSO turned on - then the case is similar to LDAP. If you don't have this enabled - then you have a case like in 1) Local.
In your use case - I'd configure it that way:
0) You rely on Internal repository (local), configure SSO / SAML; Make sure "Assign users to groups based on SAML 2.0 response attribute" is turned off.
1) Portal creates a user and assigns proper groups via REST APIs (I assume this user is also configured in SSO)
2) User logs-in via "Sign-in via SSO". SSO Authenticates successfully.
3) Dynatrace checks local in-Dynatrace user-groups mapping for that user, and assigns roles from all roles defined in groups.
Why you mentioned LDAP here at all?
I mentioned LDAP, because one of our self-service portal is connected with LDAP that works really well for users. But if LDAP is on not allowing local users, the we'll need to do it without LDAP.
So in bullet point 3, you are saying that Dynatrace could map the local user with the SAML user, if they have something in common?
Either LDAP either Local.
Maybe it is possible that you connect LDAP to your SSO provider? Then you end up with a truly "Single Sing-On" having one point of authentication.
In bullet 3 I meant the opposite -> SAML (SSO) users are mapped in Dynatrace so you can manage permissions via group assignments there.