You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Initial Concept for a TIER capable Backbone Usage Scenario  (4/27/2016)

 

This document is result of multiple phone calls and is a starting point for a Statement of Work that would enable the “Backbone Usage Scenario”.   The registry workgroup would like individuals to drive this to a deliverable that can be vetted and shared with TIER management and developers. The backbone service covers a very simple case of adding a new (SoR or invitee) person to the IAM infrastructure through to that individual gaining access to an SSO or Federated service.

Assumptions:  

  1. The installing institution should already have in place an IDP authenticating against kerberos, pulling attributes from user objects in ldap.  
  2. CoManage should be the basis for one reference implementation
  3. First pieces of another reference implementation are up and running at https://testbed.tier.internet2.edu/secure/, can we leverage this for the backbone.
  4. Challenge for the first iteration implementation: How do we reach the final step of this scenario without a true rules engine?
    1. The now famous ‘lizard brain’ (simple) rules engine is one answer. It would need to be barely smart enough to do the simple logic behind the (SoR feed)-to-(Registry user attribute)-to-(Grouper Group), and behind the process that adding to ‘faculty’ group should trigger provisioning to LDAP and Kerberos.
    2. Registry may simply say to Provisioning Consumer:: “This Resource changed and here’s its current representation”
      1.  Beyond simple add/remove faculty; one individual tends to have multiple hats, each hat implies access to a particular set of services 
      2.  People receiving (or at least “me receiving”) information may need to treat the stated “previous value” information (if it’s included) as advisory.   (Eric:  can you expand this thought from the notes)
        1. (Eric's Response:) this comment was in response to an earlier assumption that messages would contain "what (about the object) changed", "old value", "new value", and "verb (change type)". In the model outlined in 4.b. (where content is "current state" and an indication that something changed) this point may not be relevant.. 
      3.  There are potential performance issues if “send current version and expect recipient to compare to current” is an expensive operation. (E.g., compare all current group memberships to all expected group memberships might be expensive to calculate on every object update)

 

 

 

Identity Ecosystem Column

 TIER Functional Service

Functionality in BackBone Scenario

Systems of Record

Registration and Enrollment from SoR

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

Filtering/Routing/Integration Rule Engine

Rule Engine Service,

 

Registration and Enrollment from SoR>Search/Match   Entity

 

 

 

 

Credential Management

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

2.2) Invoke TIER utility to process that file

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

2.3) For ADD operations

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

2.3.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.3.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.3.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.3.5) Create group memberships based on affiliation attributes in the input feed. Drive this from a rule in lizard brain.

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

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

2.4) 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

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-provision>  Person Entity

Rules Engine

 

 

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 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 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 browse to the protected application

5.4) They authenticate at the IDP

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

5.6.1) If authenticated user isMemberOf the Instructor Group, show an hello {name} “Instructor Manual” Page

5.6.2) If authenticated user isMemberOf the Learner Group, show a hello {name} “Student Workbook” Page

 

  • What      minimal Lego-Block collection of functional interfaces are needed to actually build a proof of concept implementation?  
    • Minimal idmatch API
    • Can credential management tool like https://github.com/pwm-project/pwm or something else be leveraged.
    • Suggestion to review :  http://activiti.org .rules area...
    • Suggestion to review more use cases before worrying about products. 
    • Account / Password management - Check it out. https://github.com/pwm-project/pwm” 
      • PWM - you really need to look at that as a great option to do all the messy work for you. It can do tokens, password recover questions, reset to personal email, SMS message to mobile, and more. 
      • Based on documentation this looks like a good lego to review for consideration, devil in the details ...but it says many of the correct things.
  • No labels