Versions Compared

Old Version 1

changes.mady.by.user Chris Hyzer

Saved on

compared with

New Version Current

changes.mady.by.user EricE

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

Questions

  1. How are subjects namespaced?
  2. How is a subject represented?  What attributes are built in? (e.g. Grouper has built in name, description, id, source, and can be searched by identifier or id or either).  Or does the group service communicate with an id, and subject information is retrieved from another system.
  3. Can you get netId's back from the service or just opaque id's?

COmanage responses

  1. For COmanage Gears, subjects are namespaced within a CO (by association with CO ID) but are not further partitioned.
  2. TBD, but for COmanage Gears subjects will be associated with a CO Person ID, which can then be used to translate across other identifiers as needed.
  3. For COmanage Gears, Opaque IDs are preferred. For domesticated applications, either, but probably NetID more typically.

Grouper responses

...

  1. How are subjects namespaced: We use the Internet2 Subject API where each subject has a label of a namespace (source ID).  This seems to work fine...
  2. How is a subject represented?  What attributes are built in: Grouper has built in name, description, id, source, and can be searched by identifier or id or either.  Also the Subject API has a list of multi-valued attributes, though the WS only transmits them as single valued (and we have never had a request to change this).
  3. Can you get netId's back from the service or just opaque id's: Grouper allows the caller to specify which attributes are sent back, so the netId can be sent back to the caller on any operation

Kuali responses

  1. If I understand the concept of "subjects" as they are defined in Grouper, this includes both people and groups.  In KIM we have a bit of a different abstraction where we have the concept of "people" and the concept of a "principal" and a person can have one or more principals (which effectively represents an account).  Most things in KIM key off of the principal which is defined to have a unique identifier (which can be alpha numeric) and a principal name (which effectively represents the user name).  Groups, on the other hand, are identified uniquely by two seperate sets of attributes:
    1. by a unique identifier (which can be alphanumeric)
    2. by the combination of a namespace and a name
  2. In the case of KIM the built in attributes for a principal are it's name and it's id (there is no description).  Groups have built in attributes for id, name, namespace, description, type code, and active indicator.  As far as how the group service retrieves information on a "subject" if we are talking about a principal then it goes to a different service to get that information.
  3. In general most of our services work with the principal ids because the "net ids" are not guaranteed to remain unique over time (at least we have use cases from our implementing institutions where this is the case).

NAU responses

  1. The Grouper implementation works well for us.
  2. The Grouper implementation works well for us.
  3. ?

uPortal Responses

  1. Groups are namespaced per group service source with an identifier associate with the group service that provided the group. Subjects representing individual users have an identifier that's globally unique.
  2. User and group attributes may be locally recorded in uPortal for uPortal-managed entities, or supplied by an outside service. While the person or group must be provided with a unique ID, all other attributes are provided by the relevant service, or a combination of services. uPortal does not copy any externally-provided attributes into its database.
  3. Typically in uPortal a netID serves as the unique identifier for users.

Etc