Child pages
  • Differences between Kuali Kim Rice identities and Grouper subjects
Skip to end of metadata
Go to start of metadata

Differences Between Kualli Kim Rice Identities and Grouper Subjects

Grouper Kuali Integration

  • Rice has an entityId, and Grouper has a composite of sourceId and subjectId.  You can configure a seaprator in the which will concatenate the sourceId and subjectId.  e.g. if you use the default separator of 4 colons, and the sourceId is pennperson, and the subjectId is 12345678, then the entityId is pennperson::::12345678
  • Kuali has a principalName, and Grouper has a subjectIdentifier.  Configure which attribute is the identifier for each applicable source in the the
    kuali.identity.source.identifierAttribute.0 = PENNNAME    Note this isnt concatenated with the sourceId so it matches the principalName from the authentication service
  • Kuali has a principalId which is the id of the principalName.  The grouper connectors just uses sourceId concatenated with the separator (default is 4 colons concatenated with the subjectIdentifier.  The connector assumes each subject has one and only one identifier
  • Kuali is an identity management system with phone numbers, affiliations, privacy settings, addresses, etc.  Grouper subjects only have id, name, description and attributes.  The connector assumes you configure at least the name, subjectIdentifier (principalName), and email address.  Other stuff will be blank in Kuali.  If you need more things implemented we can discuss or you can extend the current implementation or you can use another implementation (there are some ldap ones out there)
  • Kuali has first, middle, and last name, Grouper has name.  The connector will split the name into first, middle, and last.  Soon we should put an expression language into either the first or last so that more than the name displays on the screen, to identify the subject if there are other subjects with the same name.
  • Kuali can have multiple names, Grouper could have multiple attributes that are multiple names, but the connector assumes you designate one, which will also be the default name.  Same with principals (i.e. subjectIdentifiers)
  • Some methods of IdentityService like getPrincipalByPrincipalNameAndPassword() are not applicable in Grouper and will throw an unimplemented exception.  Others like the search by params, are unimplemented and return no results.

Open notes for Kuali team

  • What does unmasked mean?  E.g. kimEntityNameInfo.setFirstNameUnmasked();
    • Currently the plugin just returns the name as the property without this designation
  • What does formatted mean?  E.g. kimEntityNameInfo.setFormattedName();
    • Currently the plugin just returns the name as the property without this designation
  • What is? getEntityNameId (unique id for this name?)
    • Since one name per person, and no id in Grouper, I just return the entityId
  • What is KimEntityNameInfo.NameTypeCode?
    • Currently the plugin returns null
  • What is KimEntityNameInfo title?  Is that Mr/Mrs/etc or a job title?
    • Currently the plugin returns null
  • What is required in KimEntityInfo besides a name (I assume a default name and that one in the list)?  Entity type?  Affiliation?  Principal?
    • Currently the plugin returns the name, entityId, active=true, entity type with work email, and principal info.  Note the external identifier list cannot be null or a null pointer exception will be thrown, this returns an empty list.
  • How do the "typeInfo"'s work?  E.g. emailtypeinfo, entitytypeinfo, etc
    • Currently the email type info is WRK: EmailTypeInfo emailTypeInfo = KIMServiceLocator.getIdentityManagementService().getEmailType("WRK");

Closed notes for Kuali team

  • Is there information on the Identity Service vs the Person Service?  Does one use the other?
    • (from Jonathan Keller): The person service uses the Identity service.  It's a facade which simplifies the object model of identity information for use by the KNS.  If you want to make sure that your person information is consistent, you will want to override the IdentityService, as there are calls within Rice which do use the identity services directly.
  • A principal has an entity id, a principal id, and a principal name.  The entity id is a unique ID for the person, the principal name is something like the netId (e.g. mchyzer), and the principal id is a DB id for that principal?  Right?  Can it be the entity id if there is only one principal per entity?  Or can it be the same as principal name?  Or is there another suggestion if Grouper doesn't have that?
From Jonathon Keller:

Throughout the system, the principal ID identifies the person given the credentials they
used to log into the system.  It is designed to be an unchanging identifier associated
with that user.  It's an abstraction for the reality that one's user ID could change for various reasons.

People may have multiple principals associated with themselves.  (Perhaps based on varying
levels of authentication or department.)  In this case, the entity ID is what ties those
records together and lets you know that they are, indeed, the same person.

If you truly don't have another identifier to use at present, you can just use your pennid
for both the principal ID and entity ID.  There's no harm in that if your existing data model
does not have a separate identifier for the person as opposed to their computing account.

    • Currently this is the sourceId concatenated with a separator, and the subjectId
  • No labels