Limited user creation (was : Creating users)

Topic created · 15 Posts · 58 Views
  • How can we avoid that users who are admins in some space create users left, right and middle?

  • Dear @aclassen ,

    I am not sure to understand your question. Could you specify your question or may be make a screenshot?

    Have a nice day,
    Yelena Yevtykhova

  • createuser.JPG

  • This is possible for a normal user, and it looks like he does not have to look into the LDAP. We want only approved users (that are in the LDAP) being added, only by superadmins or someone like that

  • Hello @aclassen ,

    Actually, in GoFAST platform, user with Standard role has the possibility to create a new user in the space he is Administrator. Super-administrator is a role for general configuration of GoFAST platform. He creates a first level of collaborative spaces and adds first administrators in the spaces of first level. As soon as the administrators are added, the super-administrator removes himself from the spaces of first level because the user with this role should not have access to the contents in spaces.

    Have a nice day,
    Yelena Yevtykhova

  • 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?

  • This post is deleted!
  • @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 ?

  • 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

  • @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

  • @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

  • @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

  • @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

  • @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

  • @cpotter Sounds good