SAML, automatic user generation

MrBaz

I setup xen orchestra with SAML login through keycloak.
It works, but the user must not already exist in XO. Remove the user, and now the user account is automatically generated in XO and can authenticate and log in. This means, literally anyone who properly authenticates will be able to log in to XO (though with no permissions). Not exactly the best practices type of thing.

Other applications either give me the option of automatic user generation, or require the user already exist (even if just a blank user shell with the username stated) in order for the user to log in to the application.

Is there a way to change this behavior?

EDIT: To add more clarification to this post, the other issue that makes this troublesome is that I can't add users to a group or setup ACLs until after that person has first logged in through SAML so their user account is auto generated. Just more administrative overhead.

olivierlambert

Question for @pdonias

pdonias

Hi @mrbaz, thanks for the feedback.

I'm not sure why it's an issue for you that the user account is automatically created in XO.

literally anyone who properly authenticates will be able to log in to XO

Isn't it the point? You seem to be raising a security issue here, but I'm not sure what it is. Could you clarify it?

Thanks!

MrBaz

@pdonias said in SAML, automatic user generation:

Hi @mrbaz, thanks for the feedback.

I'm not sure why it's an issue for you that the user account is automatically created in XO.

literally anyone who properly authenticates will be able to log in to XO

Isn't it the point? You seem to be raising a security issue here, but I'm not sure what it is. Could you clarify it?

Thanks!

For SSO and ease of setting up clients, no. Other applications I have running SSO offer me the option to enable or disable automatic user generation. Just because a user can authenticate, doesn't mean they have authorization. By only allowing automatic user generation, you break the AA scope. This means in order to safely configure the application, I have to bring additional configuration complexity to the identity management provider than necessary.

If XO had a way of pulling the user's group information and only allowing those in a certain group to have authorization to XO to have their accounts automatically generated, that would work too. Otherwise, I just do all the work on the IDP backend.

TL;DR - I can set this up securely by just adding more configuration to the IDP, but I have other hosted applications that give me the simplicity of allowing automatic user generation or not, and allowing me to manually setup user accounts on the application before their first login. What I'm asking is for more flexible options.

Security issues aside, the issue still stands that I can't put a user into a group or assign ACLs until after they have signed in for the first time. That means if I have 10 users that all sign in at 10 different times, I have to waste my time going back each time after the user has let me know they logged in and can't see anything sine they don't have any permissions.

pdonias

@mrbaz Thanks for the detailed feedback!

If XO had a way of pulling the user's group information and only allowing those in a certain group to have authorization to XO to have their accounts automatically generated, that would work too.

That wouldn't be trivial to implement with our current plugin system. But as you said, a user that logs into XO isn't able to do anything without granting them permissions first. Also, if this is still a concern for you, you can disable user auto-generation in xo-server configuration by adding this line:

createUserOnFirstSignin = false

However, you'd then have to create the users manually before they can log in.

the issue still stands that I can't put a user into a group or assign ACLs until after they have signed in for the first time.

I agree but I'm not sure what a good solution to this would be. If we add an option to import all the users at once, it could mean importing a lot of users for some companies, even if many of those users would never actually log in later.