Groups API Questions - Group Namespaces

Questions

  1. Is a Group a Subject?  i.e. can you add a group to a group with the same operation as add user to group?
  2. Deep namespace or one level namespace?
  3. Besides group namespace (folders), is there some sort of "source" for a group (e.g. group system, dynamic, group system B, etc)
  4. Can you filter operations by namespace (i.e. groups a subject is in that are in a certain namespace directly or indirectly)?
  5. Do we need something that globally uniquely identifies the group source?  (Penn prod group vs Chicago test group)
  6. (NEW QUESTION 2011/01/03): if the group namespace is deep, and represented as a string, how should it be represented? e.g. folder1:folder2:groupName

COmanage responses

  1. Yes.
  2. One level initially, although perhaps deep later.
  3. Not initially, although possibly later.
  4. This will be required.
  5. Not initially, although possibly later.

Grouper responses

  1. Is a Group a Subject?  i.e. can you add a group to a group with the same operation as add user to group?  Yes
  2. Deep namespace or one level namespace?  Deep
  3. Besides group namespace (folders), is there some sort of "source" for a group (e.g. group system, dynamic, group system B, etc): Right now grouper is the source, it doesnt aggregate multiple group sources, though maybe we should plan for that
  4. Can you filter operations by namespace (i.e. groups a subject is in that are in a certain namespace directly or indirectly)?  Yes, this is helpful for integrating with applications.  e.g. for Atlassian, the client need to get all memberships in a certain folder, not other memberships
  5. Do we need something that globally uniquely identifies the group source?  (Penn prod group vs Chicago test group)  Grouper doesnt have this but maybe it does... e.g. a URN or something
  6. (NEW QUESTION 2011/01/03): if the group namespace is deep, and represented as a string, how should it be represented? e.g. folder1:folder2:groupName   that is how Grouper does it

Kuali responses

  1. I think the answer to this question is yes, in KIM you don't do this in the same operation in order to make it explicit there are addGroupToGroup and addPrincipalToGroup operations in KIM.  But I could forsee a single operation that just takes an identifier and a member type code if others think that approach is best.
  2. We use one-level namespacing in KIM and I recall it being a conscience design to not support hierarchical namespaces and some in the community were adamant about it (though I can't recall the specific reasoning behind that).  Though from what I've seen in practice it seems like there would be some benefit there.
  3. KIM doesn't really have a requirement for that right now, we do have that case in our KIM implementation at IU (we pull groups from our Active Directory instance as well) but we use namespaces to accomplish that.
  4. KIM doesn't have that requirement at the moment, but i can't see it as being a bad feature to support.
  5. KIM does not have this requirement currently.  Is this the sort of thing that comes into play with federation?
  6. A colon delimited format makes sense to me.  Though does the string representation of a group namespace really include the group name? One other question I would have is whether or not each group namespace needs to be globally unique?  I.e. is A:B and C:B valid?  If so then any operations that can take namespace as a parameter would need to take the fully qualified namespace.

NAU responses

  1. Yes.
  2. Deep.
  3. No.
  4. Yes. This is important. For example, we identify composite, include, and exclude groups namespace.
  5. Not at this time.
  6. folder1:folder2:groupName.

uPortal responses

  1. Yes.
  2. uPortal doesn't have any concept like Grouper's folders. However, we do use the group source as a type of namespace. The source's unique key is combined with the group key to produce a globally unique identifier. The group key is also used to indicate which group service implementation should be used for retrieving group details and membership.
  3. Yes.
  4. No.
  5. Yes.
  6.  

Etc