Child pages
  • Namespace Transition
Skip to end of metadata
Go to start of metadata

Requirements

  1. Allow users to move or copy a group or set of groups from one stem to another.
  2. Allow users to move or copy an entire stem from one stem to another.
  3. For moves, optionally allow users to create an alias -- https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+aliases
  4. Expose functionality in Grouper WS.
  5. Expose functionality in GSH.
  6. Expose functionality in Grouper UI.
  7. Expose functionality in Grouper Client.

Design Details

  1. For a move, the group and stem UUIDs should remain the same.  However, the name and display name attributes will need to be updated.  The parent stem will also need to be updated for the group or stem being moved. 
  2. For a move, validate that the user has admin privileges to all groups and stem privileges to all stems.
  3. For a copy, validate that the user has read privileges to all groups.
  4. If a group that's moving is a factor of a composite, it should continue to be a factor after the move.  However, if you're copying a group that's a factor of a composite, the new group will not be a factor.
  5. For a move, all access privileges, naming privileges, attributes, and custom lists should be moved.  Also, after a group move, populate the name_history attribute of the group with the old group name.
  6. For a copy, allow users to choose which memberships, privileges, and custom attributes to copy.  If the group being copied has aliases, those aliases should not be copied.  Also, the name_history attribute should not be copied.
  7. LDAP-PC should apply these namespace changes to LDAP in an efficient manner.  I'm not sure how LDAP-PC would currently react to these changes, so that's something that may need to be looked at.
  • No labels

4 Comments

  1. Unknown User (mchyzer)

    We should also expose functionality in grouper client.  I can do the client and WS stuff if you like.  If not, I will need to document what needs to be done to add a new web service / client operation.  Let me know either way. 

    Another Grouper feature I am interested in is Grouper name aliases (and maybe stem names too???)  This is so that if a group is renamed, the alias is still valid, since that is what web service clients or ldap client refer to things as.  Anyways, regarding this though, maybe that should be an option for namespace transition on move, if an alias should be kept (required param with no default?).

     Regarding question #1 about if the new group should be a member of existing members... for a move, I think yes, and a copy, I think not.  Is there a use case for not doing those?

    Chris

  2. Unknown User (shilen)

    I'll add the Grouper Client to the requirements and at some point, I'd like to take a shot at doing something with the WS and this might be a good time. 

  3. Unknown User (gary.brown@bristol.ac.uk)

    Regarding 4 and copying a group that is a factor, if the composite itself is being copied as part of the same operation, then the composite copy should be created and the factors should be the newly copied groups i.e. if you have a stem (ARTF) containing 3 groups

    1. ARTF_staff
    2. ARTF_students
    3. ARTF_staff_and_students

    where  ARTF_staff_and_students = ARTF_staff union ARTF_students, and you copy the ARTF stem to SCIF there should be a new SCIF_staff_and_students = SCIF_staff union SCIF_students

    NB I suggested in a response to Tom that it should be possible to modify extensions using any of prefix / suffix / regular expression / interface

    The type of copy suggested above is achievable currently using XML export and import, though to change the extensions you would need to edit the exported XML.

  4. Of potential provisioning approaches with ldappc, it seems that ldappc could handle stem or group renames via (1) a changelog or (2) by being able to lookup a group in an ldap directory by something (old_name, uuid, alias) other than the current group name.

    Attaching ldappc to a changelog probably depends upon the auditing/notification work.

    For ldappc to determine that a group or stem should by modified via modrdn or moddn it will need to know the current ldap dn and the new dn. If ldappc has access to current and old_name's, then it could determine the current and new dns. However, the old_name namespace would likely need to be unique, which is potentially unworkable, given the case of 'swapping' the names of two groups. At the very least, the most-recently-used-old-name should be unique across the old- and current-namespace, which would disallow name-swapping.

    Another approach besides tracking name history is to store opaque UUIDs in ldap, probably in a configureable indexed attribute. Some directories and implementors may be amenable to modifying or extending schema, others not. Or perhaps, a unique identifier determined by the ldap directory (e.g. someting ActiveDirectory SID-like) could be stored in grouper.