Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Let's have a look at these three areas.

Source systemssystems   

<== add staged identity onboarding (Keith)

As a demonstration of source systems let's use the following (extremely simple) three tables:

Each person has:
  1. zero or one department membership (e.g. BusinessLaw, and so on),
  2. zero or more affiliations (student, facultystaffmember, alumcommunity),
  3. zero or more course enrollments (e.g. CS251MATH101, and so on).
To summarize the data representation in SIS:
What
How
Example
person
row in SIS_PERSONS table
# uid, surname, givenName, fullName, department, mail
'bgasper', 'Gasper', 'Bill', 'Bill Gasper', 'Business', 'bgasper@example.edu'
person's department
department column
Business
person's affiliation
rows in SIS_AFFILIATIONS table
# uid, affiliation
'bgasper', 'alum'
person's courses
rows in SIS_COURSES table
# uid, surname, givenName, courseId
'bgasper', 'Gasper', 'Bill', 'CS251'
'bgasper', 'Gasper', 'Bill', 'MATH100'
(Actually, specific SQL representation is quite irrelevant, because SIS tables serve here only as a simplified version of a real academic information system.)
midPoint and Grouper
Via midPoint and Grouper we want do achieve the following:
  1. To modify selected information from SoR by including and/or excluding given persons to/from given groups.
    1. This applies to affiliation information: For example we might want to state that although bgasper is listed under alum he should actually not be in alum but in faculty.
    2. Departmental and course information do not need to be changed in this way.
  2. To create extra groups and manually maintain their members.
  3. To create extra groups that aggregate information from other groups.
In these scenarios we decided to use group-management features of Grouper to implement the above requirements.
Data in midPoint
In midPoint the data is represented like this:
What
How
Example
person
user
bgasper
person's department
user  org (of subtype department; under Departments org)
bgasper  Business
person's refined affiliation
user  org (of subtype affiliation; under Affiliations org)
bgasper  Affiliation: faculty
person's courses
user  org (of subtype course; under Courses org)
bgasper  MATH100, CS251
person's mailing list membership
user  org (of subtype mailing-list; under Mailing lists org)
bgasper  Mailing list: chess, Mailing list: idm-fans
person's other membership
user  org (of subtype generic-group; under Generic groups org)
bgasper  test:volunteers, app:cs
An example:
Image Modified   Image Modified
Relation targets (departments, affiliations, courses, mailing lists, other groups) are modeled as midPoint organizations.
TODO some screenshots here
Data in Grouper
What
How
Example
person
subject referencing LDAP entry
uid=bgasper,ou=People,dc=internet2,dc=edu
person's department
membership in ref:dept:XXX group
ref:dept:Business
person's affiliation (from SoR)
membership in ref:affiliation:XXX_systemOfRecord groups
ref:affiliation:alum_systemOfRecord
person's affiliation (refined)
membership in ref:affiliation:XXX groups
ref:affiliation:faculty
person's courses
membership in ref:course:XXX groups
ref:course:MATH100, ref:course:CS251
mailing list membership
membership in app:mailinglist:XXX groups
app:mailinglist:chess, app:mailinglist:idm-fans
computer science course enrollment
membership in app:cs group

any other membership
membership in respective groups
test:volunteers
An example:
Image Modified
Target systems
Target 1: Faculty portal
All users having affiliation of faculty (potentially modified in Grouper) should have a record in faculty portal database, carrying the following information: uidgivenNamefamilyNamefullName, mail.
Note
This resource is temporarily created as a CSV.
Data representation:
What
How
Example
person's record
A database table row (temporary a line in CSV)
bgasper,Bill,Gasper,Bill Gasper,bgasper@example.edu (temporary in CSV)
Image Modified
Target 2: Computer science students portal
All computer science students (enrolled in CSxxx courses) should have a record in this system, providing the following information: identifier (i.e. uid), name (i.e. fullName), mail, computer science courses enrolled in.
Data representation:
What
How
Example
person's record
A line in CSV file
dlangenberg61,Donna Langenberg,dlangenberg61@example.edu,CS251;CS252
Image Modified
Target 3: Generic mailing list application
This application expects to get the set of pairs of (listNamemail) describing membership of individual mailing lists.
Note
This resource is temporarily created as a CSV, represented as a set of (username,mail,list-of-mailing-lists) triples.
Data representation:
What
How
Example
mailing list membership
A line in CSV file (temporarily)
bgasper,bgasper@example.edu,chess;idm-fans
Image Modified
Of course, all this information required by targets 1-3 can be taken directly from LDAP. But we want here to simulate resources that need some extra processing (e.g. Box, Office365, and so on) leading to the use of a specific connector.
Target 4: LDAP
In order to provide information to a lot of other systems we need to maintain LDAP directory where each user has an eduPerson record with the following attributes or relations set (among others)
What
How
Example
person
eduPerson object with givenNamesncnmail containing corresponding information from sis_persons table i.e. givenNamesurnamefullNamemail, respectively
uid=bgasper,ou=People,dc=internet2,dc=edu
person's department
businessCategory attribute
Business
person's affiliation (refined by inclusion/exclusion)
group membership (in ou=Affiliations,ou=Groups,dc=internet2,dc=edu groups)
cn=faculty,ou=Affiliations,ou=Groups,dc=internet2,dc=edu
person's courses
group membership (in ou=Courses,ou=Groups,dc=internet2,dc=edu groups)
cn=MATH100,ou=Courses,ou=Groups,dc=internet2,dc=edu
cn=CS251,ou=Courses,ou=Groups,dc=internet2,dc=edu
person's other Grouper groups
group membership (in ou=Generic,ou=Groups,dc=internet2,dc=edu groups)
cn=app:cs,ou=Generic,ou=Groups,dc=internet2,dc=edu
cn=app:mailinglist:chess,ou=Generic,ou=Groups,dc=internet2,dc=edu
cn=app:mailinglist:idm-fans,ou=Generic,ou=Groups,dc=internet2,dc=edu
cn=test:volunteers,ou=Generic,ou=Groups,dc=internet2,dc=edu
person's midPoint-managed groups
group membership (in ou=midpoint,ou=Groups,dc=internet2,dc=edu groups)
cn=sysadmingroup,ou=midpoint,ou=Groups,dc=internet2,dc=edu
An example:
Image Modified
Design options
The two options differ in how group membership is transferred from source systems to Grouper.
In the first one ("All interfacing via midPoint") midPoint is solely responsible for getting the data and providing it in the cleaned form to Grouper:
Image Modified
The idea behind this option is to concentrate all interfacing at a single place: into midPoint, which has strong features in this area.
In the second one ("SoR groups to Grouper") midPoint gets only data about persons. Data about groups are transferred from source systems directly to Grouper:
Image Modified
The idea is to reduce the amount of data going through midPoint: if we ultimately want to have all groups in Grouper, and we only need some of them to be provisioned to target systems, it is not necessary to pull this information through midPoint.
The discussion on these options is at the end of this document (TODO); we might note, however, that both have their own rationale, and the ultimate selection among them depends on particular circumstances.
Discussion of the options
TODO
Option 1 requires the representation of "raw" SoR data that is flowing through midPoint via LDAP to Grouper. According to the current requirements this is the case of person's affiliation that is refined in Grouper.
So in option 1 we have the following additional data items:
What
Where
How
Example
person's affiliation (from SoR)
midPoint
user's rawAffiliation extension property
alum
LDAP
eduPersonAffiliation attribute
alum
TODO
Note: Although Option 1 resembles the demo/complex on the master branch, it is a bit different. For example, raw affiliation (taken from SoR) is not represented as midPoint role membership but only as rawAffiliation extension attribute. The membership in generic groups taken from Grouper is represented by midPoint org membership and LDAP group membership, not just by extension property value setting as was in original demo/complex scenario.