GitLab administrators will have the option to modify attributes for users provisioned by their group's SAML or SCIM integration. In this first iteration, administrators can reduce the risk of accidental exposure of their intellectual property by preventing their users from creating groups or projects outside of groups they are not already members of.
Problem to solve
Enterprise customers want more control over accounts in their group. See &4786 for more information.
Proposal
For accounts that are being provisioned using SAML JIT, give administrators the option to create users that can only create groups/projects within their top-level group. To achieve this, we can allow administrators to set users will have a "Project limit" value to 0 and "Can create groups" to false.
This setting will only be forward-looking and effective on users created after this setting is enabled. We will have a separate issue to apply these values to existing users.
@alexpooley@mksionek@dblessing This is one of the issues we talked about today during our sync up. Can you please take a look and let me know if there are any outstanding questions? If not, please assign a weight to it.
Something I discussed with @dblessing during our 1:1 was whether custom attributes could be passed from the IdP as part of User provisioning. So instead of having implicit behaviours depending on how an account is created or based on some configuration, you would pass explicit attributes when creating the user. As an example, we could extend https://docs.gitlab.com/12.10/ee/api/scim.html#create-a-saml-user to accept a project_limit attribute.
Ultimately this is a trade-off between complexity vs flexibility, but at least might be worth considering when we have lots of customers with unique provisioning requirements.
@lmcandrew I like this idea because it's a model that is extensible to other values in the user object. For SAML provisioning it can work the same way. We can ask users to pass an attribute and if we find it in the SAML assertion we set the value when we create the user.
I quickly looked at the SCIM spec and I can't quite tell what's supported. According to the spec it seems like the schema is fairly fixed unless you define a new schema. Some of the most common schemas can be found at https://tools.ietf.org/html/rfc7643#section-8.
But it also looks like Okta might allow easily adding additional fields.
This will require some more investigation to figure out the best path.
@dblessing Thanks for looking into this! It makes sense that with SCIM we need to follow a spec so we may be more limited. It may make more sense to allow group administrators to set the default values for new users, like we do for the default role for SAML. Later we can expose an API that allows them to edit these values on existing users.
@lmcandrew Let me know what other information you need from me to get this workflowready for development . I'd hate for it to miss %13.7 ! If we need to get together for a quick conversation let me know 👍
@dblessing thanks for your initial investigation in to this.
From looking at the RFC I understand this is what the entitlement User attribute could be used for:
A list of entitlements for the user that represent a thing the user has. An entitlement may be an additional right to a thing, object, or service.
However, as an MVC it may make the most sense to check the payload we receive from Okta when using additional fields then integrate against this.
For SAML provisioning it can work the same way. We can ask users to pass an attribute and if we find it in the SAML assertion we set the value when we create the user.
To @mushakov's point, we would ideally want the method to work for SAML provisioning as well. @dblessing given all of this, do you feel the issue is ready to refine? If so, how do you feel about picking it up as your next priority? I see you have already made great progress with #268142 (closed). We could also get others involved if it will help our chances of delivering in %13.7.
@lmcandrew Thanks for the tip on entitlements. There's not a lot of help in the spec on exactly what an entitlement looks like and how to use it. In some implementations I see it as a separate endpoint.
This seems like it has promise. I would need to test to see exactly how that comes across in the SCIM payload Okta sends, but I think this is our best bet for the first iteration.
Assuming the above is fruitful, I think the change is somewhat easy:
Set up the test in Okta, following the same principles as the link above. This seems to be compatible with both our Okta GitLab app or a test SCIM app in Okta.
Modify the SCIM API and ProvisioningService to accept the new mappings for can_create_group and project_limit.
Update documentation.
I'm going to estimate this as weight 5 because the potential for problems along the way is fairly high. But if everything goes as planned the number of code changes should be limited.
@mksionek Do you mind reviewing my assessment, please?
@lmcandrew In terms of getting this done for %13.7, it would compete with https://gitlab.com/gitlab-org/gitlab/-/issues/262658. I'm happy if we can assign one of these to another person. Maybe it's more efficient to have me take this SCIM issue based on my experience and the unknowns?
@dblessing Would splitting this issue into the SCIM approach and SAML provisioning make sense? The specific customer that wants this in the short term would be using SAML provisioning. It seems like there are fewer unknowns there.
@mushakov Yes, SAML implementation would be easier with less unknowns. We can support a new attribute section like Groups to specify these user attributes.
If we're adding multiple places for these attributes to be set (SAML and SCIM) we may want to consider adding some sort of tracking and priority later on. What happens if SAML and SCIM both try to set these values. Technically if they are connected to the same provider the values should be the same, but if they're not then they could fight and each set the values back and forth. That might be an edge case, but something to consider.
@dblessing I really like the idea of the conceptual approach being similar to the Groups attribute in Group Sync. It will appear a logically similar use case to the end user. I am not a UX expert but it feels consistent.
Melissa Ushakovchanged title from Provisioned Accounts - SCIM accounts exclusive to top level group to Provisioned Accounts - Accounts exclusive to top level group
changed title from Provisioned Accounts - SCIM accounts exclusive to top level group to Provisioned Accounts - Accounts exclusive to top level group
Melissa Ushakovchanged the descriptionCompare with previous version
changed the description
Melissa Ushakovchanged the descriptionCompare with previous version
Melissa Ushakovchanged title from Provisioned Accounts - Accounts exclusive to top level group to Provisioned Accounts - Allow setting "Project limit" and "Can create groups" attributes
changed title from Provisioned Accounts - Accounts exclusive to top level group to Provisioned Accounts - Allow setting "Project limit" and "Can create groups" attributes
Melissa Ushakovchanged the descriptionCompare with previous version
changed the description
Melissa Ushakovchanged the descriptionCompare with previous version
@bmiller1 @spouliquen1 @jrreid Tagging you have customers that would be interested in this feature. To take advantage of this functionality, we would like for a value to be passed from the customer's IdP. They would make a change in Okta/Azure/etc to pass values for what they want the "project limit" and "can create groups" attributes to be. This would allow them to give certain people, like their admins, more flexibility while restricting the experience for everyone else. It will require some changes in their IdP though. Can you let me know if this sounds like a good approach for them?
Notice the two new attributes near the end - can_create_groups and project_limit. In Okta these can either be a dynamic mapping to a user's profile, or a literal string value. Here I just set the literal value of 'true' and 10, respectively.
Hello - This looks great, and I like the approach. From what I have read, it looks like it would meet one of our needs well - the API aspect would also be greatly appreciated.
Question 1 - would this also prevent the creation of projects/groups in the users personal space?
Question 2 - the API aspect, are these attributes already something that could be toggled via the API and achieve the behavior above, or is this #263661 (comment 450143338) stating that an API would be created to allow this to be done?
@shaun_baker The first iteration will be via SAML only, and the settings will be set during sign-in. Later we will add SCIM API support, but that's only intended for SCIM providers like Okta, Azure, etc.
Question 1 - would this also prevent the creation of projects/groups in the users personal space?
Yes it would prevent creation in personal namespaces.
Question 2 - the API aspect, are these attributes already something that could be toggled via the API and achieve the behavior above, or is this #263661 (comment 450143338) stating that an API would be created to allow this to be done?
An API would need to be created. This initial implementation would be done by reading SAML attributes.