GitHub user dstoy53 added a comment to the discussion: Auth provider 
extensibility: stop requiring a core code change for every new SSO/OAuth/OIDC 
vendor

I think it's also worth revisiting the automatic user creation behavior with 
sso unless that adds too much scope to the discussion. Something similar to 
linkAccountToLdap, but more of a mapping of oidc claims to accounts for a 
trusted oidc provider. 

I use keycloak with user federation via ldap, and when 4.23 lands I suspect my 
workflow will look a bit like this:

1. create an Account+custom Role for a team
2. link the team's ldap group to their Account
3. expect first time users to log in with ldap user/pass to create their 
initial cloudstack user
4. allow keycloak oidc auth matching on the email claim

My use case is strictly internal users, and Accounts are only used for user to 
role mapping while resources are owned by Projects. 

As a root admin, having the ability to map oidc claims (such as 'groups' where 
the user is a member of 'engineering') to an Account (and therefore role) 
allows me to skip ldap config in cloudstack entirely. This will also be useful 
for people whose oidc IdP isn't backed by ldap since it'll save them from 
whatever mechanism they use to spawn the initial user. 

I think the original decision to disable automatic user creation for sso was to 
mitigate risk in more open social login environments, but giving an admin the 
ability to map a trusted IdP to an account (and/or domain) should also mitigate 
that. 

GitHub link: 
https://github.com/apache/cloudstack/discussions/13865#discussioncomment-18164664

----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]

Reply via email to