Child pages
  • Differences between Grouper and Kuali Rice KIM Groups
Skip to end of metadata
Go to start of metadata

Differences Between Grouper and Kuali Rice KIM Groups

Grouper Kuali Integration

As the  connector is developed, the differences between Grouper and Kuali Rice KIM will be noted.  Some of the differences are requirements for enhancements to Grouper to bridge the gaps.  Some differences are for informational purposes.

  • KIM uses incrementors are IDs and Grouper uses UUIDs.  This can lead to issues if the groups you fronting from KIM to Grouper originate in KIM first.  If this is the case we can augment the connector to convert the incremented ID to a UUID.  We need to discuss this.  Best case is the groups are created in KIM after the connector is in place, in which case it will use UUIDs, or they exist in Grouper or are created in Grouper.
  • KIM has a name for a group.  Grouper has two names for a group, a system name, and a friendly name.  The system name should not change often.
  • The KIM services are largely driven by UUID.  The architecture for the connector uses the Grouper client which generally had not used UUID as an identifier for operations, since the system name should not change often.
    • Note: the Grouper client was enhanced in 1.6 to have the ability to refer to objects by UUID instead of by system name
  • KIM does not have a namespace on subjects, but grouper does have a one level deep namespace for subjects (sourceId).   The subjectId in Grouper is similar to the principalId in KIM, both should be an identifier which never changes (e.g. at Penn we have PennID, which is an 8 digit number.  It is not our PennName, which is a 8 char alphanumeric which changes sometimes when people change their names).
  • KIM has an active flag on a group, and grouper does not.  If an inactive group is stored to grouper, an exception will be thrown.
  • KIM group description is varchar(4000), but Grouper is varchar(1024).  If the description is more than 1024, it will be abbreviated to 1024 (with ellipses).
  • KIM has an operation for adding or updating a group.  Grouper can add, update, or add_or_update a group. To keep things simple, the grouper add_or_update will not be used.
  • KIM refers to a group name the way that Grouper refers to a group extension (API terminology).  The namespace in KIM is the stem in grouper.  The group name in Grouper is the namespace concatenated with a colon, concatenated with the group extension
  • KIM has an operation where you can select multiple groups by ID.
    • Grouper had a way to use a complex OR'es quer, but a more straightford way was added for selecting by names or uuids for groups or stems.
  • KIM has a lookupIds method where you can put in criteria and it will return group ids. This is not [yet] implemented in Grouper
  • KIM can get the groups for a subject in a folder only in that folder or in that folder or subfolders.  Grouper could only get all groups for a person
    • Note: the Grouper client and WS was enhanced to get groups in a folder or subfolder
  • Kim can get all groups for a subject, or the direct groups, or indirect groups, grouper could not do that from the grouper client
    • Note: the Grouper client and WS was enhanced to get all, direct or indirect groups for a subject
  • Kim can get immediate or non immediate members of a group.  Grouper could get immediate, effective, or composite members.  The gap was the effective union composite members
    • Note: the Grouper client, WS, and API were enhanced to be able to retrieve nonimmediate which is the effect and composite together
  • Grouper could get the group members of a group, or the subject members of a group.
    • Note: the Grouper client, WS, and API were enhanced to be able to retrieve members of a certain subject source
  • Grouper WS/client could not filter members in one call by sourceId
    • Note: the Grouper client, WS, and API were enhanced to be able to filter members by a sourceId
  • Kim could get the memberships of a group, but grouper could not.
    • Note: the Grouper client, WS, and API were enhanced to be able to retrieve memberships
  • Kim creates new groups in what could be new namespaces (to Grouper).  Grouper was enhanced to allow the param "createParentStemsIfNotExist" to the groupSave service
  • Kim caches group information for 30 seconds by default.  It is possible for changes in Grouper to trigger a service call to Kim to refresh the cache.  For now, this is not done and there is a 30 second propagation delay from Grouper to Kim.
  • Kim might only allow one type to be applied to a group (question for Kim team), Grouper can have many types applied to a group

Open notes for Kuali team

  • When I route to a group (e.g. here), and I change the membership of the group, then I wait a minute, then I submit an edoclite, it uses the old members.  How can I make it only cache for 30 seconds or something shorter?
  • It would be nice if the rice-impl.jar didnt have a in it, since we use p6spy too and it can cause some difficult to diagnose errors
  • I see requests for principalId "1", is that a special principal that needs to be resolvable in Grouper?
  • Can a group have one and only one Group type?
  • Why does the group list screen show all the sample group data when there is no search critieria and not use the Grouper service?
    • Answer: Rice assumed that if you implemented the GroupUpdate service, you would not use the Rice UI for Groups operations.  Eric sugested they change Rice for this.

Closed notes for Kuali team

  • On the APIit says many operations return true or false, but it doesnt explain what they mean.  I assume true means an action took place, and false means it didnt (already existed).  Is this correct?
    • Answer: yes
  • Grouper group attribute names need to be defined in advance.  Is there a list of KIM attributes that can be applied to a group?
    • Answer: I think you would need to define a Kim Type, and then define the attributes for that type.  Use that type to make the groups.
  • In createGroup, it takes as an input GroupInfo, and returns GroupInfo.  Is it supposed to return the same object as was passed in, and add the groupId to it that was assigned?
    • Answer: It actually is supposed to get the new group that exists in the database.  This could be different because the id or some defaults may not have been set.
  • If there are no attributes in a Grouper group, should the GroupInfo.attributeSet be null or empty or doesnt matter?  Same question for all methods that return a list.
    • Answer: We've talked recently about changing all of these to return an empty list, but for the time being it would probably be safest to check for null and empty sets.
  • Whats the spec for lookupGroupId() the criteria etc
    • Answer: Essentially just a map of keys and values.  The key being the BO's fields (groupId, groupName, namespaceCode, etc).   Look at this doc
  • What is memberTypeCode in GroupMembershipInfo?
    • Answer: P for principal (user), G for group.
  • Are the GroupMembershipInfo services only supposed to return enabled memberships?  Or all memberships?
    • Answer: Just the active memberships.
  • Is the memberId of a GroupMembershipInfo be a groupId or principal id depending on type of member?  What is groupMemberId?  What is memberTypeCode?  Is it ok if the version number is 1 all the time?  (this seems like an internal detail that I would prefer not to expose through the Grouper WS)
    • groupMemberId is just the unique Id for the krim_grp_mbr_t table.  memberId is either a groupId or principal Id depending on the memberType.
  • Is this how I override the groupUpdateService?  I dont see it overriding in the logs:
<beans xmlns=""
  <bean id="kimGroupService" class=""/>
  <bean id="kimGroupUpdateService" class="edu.internet2.middleware.grouperKimConnector.groupUpdate.GrouperKimGroupUpdateServiceImpl"/>
    • Answer: No, you should just have the GroupUpdate service be implemented by the class that implements the GroupService, then do not have a separate line in the config for kimGroupUpdateService, since that is a spring alias. However, the rice team discussed changing this in the future so it would be separate.
  • No labels