Versions Compared

Key

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

...

The Backbone Usage Scenario is intended to illustrate the simplest possible end-to-end example of TIER in action by implementing a functioning example. The story we will demonstrate begins witih with a new hire or a new student arriving at a hypothetical university, having their basic ERP-based demographic and affiliation information incorporated into the core entity registry, including passing through an identity match process to determine if the person is already represented in the registry.

Once in the registry, the new arrival should be provisioned with an account , and credentials and pushed into in a general purpose LDAP directory. Further automated transformations on the ERP data are used to populate basic affiliation groups in Grouper (in this proof of conceptdemo, the affiliations are either will be faculty or student). Finally, there is a Shibboleth-protected "Learning Management System" accessed by the faculty member or student through SAML-based Web-SSO. The LMS will display either a course design page (for faculty) or a course catalog (for students).

...

Identity Ecosystem Column

 TIER Functional Service

Functionality in BackBone Scenario

Systems of Record

Registration and Enrollment from SoR (KH)

1.1) Provides periodic feed (most SoRs can do this today, daily, hourly, etc)

Filtering/Routing/Integration Rule Engine

Rule Engine Service (SteveC)

 

Registration and Enrollment from SoR>Search/Match  (KeithH)

 

 

 

 

Credential Management (WarrenC)

 

Rule-Driven Group Management (SteveC, ChrisH)

 

2.1) For each SoR person, use the IdMatch API (stub only for now) to see if this person already exists in the Registry

2.32) For ADD operations

2.32.1) If IdMatch found, update the existing Registry entry (un-soft-delete if necessary)

2.32.2) If no match found, create a new Registry entry, and   send “new user” event in the Lifecycle Management Engine (lizard brain or ?)   which triggers replication to LDAP and Credential Store

2.32.2.1) LDAP and Kerberos for reference implementation? The Shib plug-in for Web SSO authentication is the integration point for alternate AuthN methods

2.32.3) Assignment of a one-time token good for a userid/password credential (or challenge questions? (both approaches have   been discussed) 2.3.4) Notify user to visit “Activate” page.

2.32.5) Create group memberships based on affiliation attributes in the input feed. Drive this from a rule in lizard brain.

    • Translate the syntax/semantics of the local feed to standard TIER format

    • Invoke TIER utility to process that file

2.32.5.1) If AFFILIATION from SoR = faculty or staff then add person to Group “Instructor”

2.32.5.2) If AFFILIATION from SoR = student then add person to Group “Learner”

2.43) For DROP operations, TAG the user appropriately in the Registry (“soft delete”); this would cause updates in LDAP and Kerberos (expire account), and remove them from groups.

Repositories

Repository Components (BennO??, Keith)

3.1) Provide  IdMatch API

3.2) Provide Add Person API

3.3) Provide DROP Person API

3.4) Provide add person X to group Y API

3.5) Provide remove person X from group Y API

Provisioning

/Rules Engine

Provision/De-provisioning Person Entity (BillT with help from JonM)

Rules Engine (SteveC)

 

 

4.1) When person is added replicate them to ldap

4.2) When person is added replicate them to kerberos

4.3) When person is dropped flaf as soft-deleted or remove them(?) from ldap

4.4) When person is dropped remove/disable them from kerberos

4.5) When person is added to group update linked ldap group

4.6) When person is dropped from a group update the linked ldap group

Capabilities of the backbone and associated   application.  Demo in this manner…

 

5.1) Configure the sample Service Provider application (TBD) to use Shibboleth as its Web SSO mechanism

5.2) Configure requested attributes element on Shib session protected endpoints, ask for displayName and isMemberOf

5.3) Have a registered user users browse to the protected application

5.4) They Users authenticate at the their IDP

5.5) Depend on LDAP or Kerberos for the initial user authentication behind the IDP, Release attributes X, Y, Z to the sample   SP  application

5.6.1) If authenticated user isMemberOf the Instructor Group, show a hello {name} “Course Design” page

5.6.2) If authenticated user isMemberOf the Learner Group, show a hello {name} “Course Catalog” page

...