Limited user creation (was : Creating users)

[aclassen]

Oh, but even if they are administrators in their space, they should not be able to create users.

• For example, we need to restrict the number/type of users that have access to internal resources by design.
• We also want to avoid people circumvent our SSO unless in very specific exceptional cases
• And we need to restrict the number of users for licensing/subscription reasons

But we should allow internal users to create their specific subspaces they only want to share with, let us say, one or two colleagues (imagine something about HR - imagine a disciplinary action), so they must be administrators somewhere.

So what is the right scenario?

[cpotter]

This post is deleted!

[cpotter]

@aclassen The fact that space administrator can create user accounts is our initial concept where business units have a broad delegation, a concept adopted by all our current customers. However we understand your more restrictive point of view.

We could ask a quotation to the IT team about a "configuration switch" that does the following :

• in case of a automatic daily AD synchronization, a space administrator could only create an extranet user
• this extranet user cannot be added to organization space/sub-space (and eventually to group space/sub-space)

This restriction could match some future needs of most of our customers that want a user creation restricted mode.

What do you think ?

[aclassen]

That is a good step forward, though for our current work processes and internal controls, it should be in any case only a superadmin or an admin in the top level spaces (organisation, groups, extranets first or perhaps down to admins in level 1/under that) that would be able to create any user.
That means, while your suggestion is better than the current situation, it would still require us to change the way about who approves a person having access to something, and it would seriously put our intended security restrictions (enforce SSO/2fa for those extranet users, or let them use the same password for whatever service they have access to beyond GoFAST) at risk. The "access to other systems for Extranet users with the same password" is not a small issue, because GoFAST and document centred work is just one form of collaboration. We use very specific data collection systems with Extranet users, and they are used to jump from one to the other with the same username/password combination for all systems they have access to.

I could think of a variation fo your proposal,

• in case of a automatic daily AD synchronization or if LDAP is configured, a space administrator could only create an extranet user with search in LDAP and authentication against LDAP obligatory
• this extranet user cannot be added to organization space/sub-space (and eventually to group space/sub-space)
• ideally this would be restricted to space administrators on level 0 and 1

Your version could also work if we develop first in our organisation a process to allow and manage that, to hold users outside of our LDAP.
Anyway, I see that it is a change request requiring an estimate

[cpotter]

@aclassen i have the feeling we could reach your goal differently and perhaps in an easier way :

You want all your users (incl. Extranet) to log with SSO (incl. 2FA), therefore being already in your Directory and created in GoFAST by a daily sync
Please note that we understand EMCDDA policy but this is the opposite of all our current customers where they don't want Extranet users created in their Directory.

Proposition :

1. a GoFAST configuration could be here to accept only SSO logins disabling users creation from GoFAST ?
   Space administrator will have therefore only the task to add users to their space (with the following restriction)
2. an Extranet user cannot be added to an Organization and Group space (and to simplify i think we should exclude adding Extranet users to lists, otherwise when a list is added to a org or grp space all membes must be checked if they are Extranet or not)

We will still need to have a quotation from my devops teams

[aclassen]

@cpotter That - to only allow SSO login (perhaps with an exception that existing local users remain, for administration by CEO-Vision for example?) - would be perfect.
So space admins would only add/remove from their spaces.

Excluding Extranet users from Groups and Organisations: very good

The restriction to add Extranet users to userlists: I am not sure about that. Do you mean for the manual addition of users? We do want to use LDAP-synched/fed userlists for access rights, and those may have Extranet users, and I do not think we should check or reject them at the time of synching, do you? OK, the big LDAP-groups that are Extranet-related will likely have nothing to do with GoFAST. This last detail is still not clear to me

[cpotter]

@aclassen well i am not sure we can have exception to the "SSO No GoFAST user creation". Perhaps you will have to create it in your AD as well (will need advice from my team)
For the lists, the problem is that there should be a complex development to check if there is an Extranet user added to a list used in Org/Grp (synchronized or not) and it will be i assume impossible to do this check on your AD side.
Therefore you will have to make the assumption that if an Extranet user is added to a list, potentiality he could end up in an Organisation or Group

[aclassen]

@cpotter i am not sure we can have exception to the "SSO No GoFAST user creation"
That would not be a problem, it was just a thought bearing in mind existing admin users. No problem to create them in AD/LDAP (we do that in nearly all our systems)

Therefore you will have to make the assumption that if an Extranet user is added to a list, potentiality he could end up in an Organisation or Group - OK, indeed I would not like to even ask for any complex checking concerning user lists unless anything really easy were to spring to our minds. And no problem - we do control the AD/LDAP side that could be used for synch, the only potential issue concerning groups/organisations can be tackled by monitoring (certain) space memberships

[cpotter]

@aclassen After some discussion with the IT team, the user creation should be 'grayed' (in menus) when the directory sync is in place (and not the SS0). It sounds logical to me

[aclassen]

@cpotter Sounds good

[aclassen]

Can we get back to this topic, in the simplest way possible?

• Admin-Users should only be able to add somebody who is on LDAP

• We would like to enforce SSO/SAML or at least hide the standard login form.

[cpotter]

We have currently a development planned (GOFAST-6369, could be v4.0) to "grey" (avoid) the user creation menu entry when directory sync is in place, we were waiting i think for the order form.
For the removal of standard login form, not sure a quotation and impact assessment/feasibility as been done by CEOV, can you confirm ?

Best,
Christopher

[aclassen]

I think it would be nice to discuss this in a short meeting