Meeting Details: Tuesdays, 4:00 - 5:00 pm Eastern Time, 1:00 - 2:00 Pacific Time
   Dial-in numbers:
       +1-734-615-7474 (Please use if you do not pay for Long Distance),
      +1-866-411-0013 (toll free US/Canada Only)  
    Access code: 0150432#

Participants

Who

With

Attending

Omer Almatary

Rutgers University

 

Rob Carter

Duke University

√

Celeste Copeland

Univ. of North Carolina

√

Warren Curry

U Florida

 

Michele Decker

U of Notre Dame

 

Tom Dopirak

CMU

√

Jeremy Grieshot

Clemson University

√

Keith Hazelton

UW-Madison / Internet2

√

Karsten Huneycutt

Univ. of North Carolina

 

Steve Olshansky

Internet2

 

Derek Owen

U of Notre Dame

 

Andrew Petro

Unicon

 

Chris Phillips

Canarie, CA

 

Gary Sharpe

UC Davis

 

Muhammad Siddique

Rutgers University

√

Bill Thompson

Unicon / Jasig

 

Boyd Wilson

Clemson University

√

AGENDA (See meeting notes for more detail)

  1. The Clemson University provisioning connector architecture (and possible use in CIFER)  (Boyd Wilson)
    1. NetIQ XSLT might be more site specific vs. Scripts that know how to talk to specific endpoints are the more interesting shareable bits;
    2. Does need to have the concept of a filter, etc. Might have to build something to do a message bus version of this. Something that directs who cares about what.
    3. Synergy around ActiveMQ; Jeremy can look into that; Wiring to the bus; two layers to the discussion; If either CPR or OR put events on the bus, what's the common model? SCIM? SPML?
    4. The technology is more generic than person identity info provisioning
  2. Provisioning at Rutgers using Open Registry (Muhammad Siddique)
    1. Use CAMEL at both producer (of events) dB table of the queue. event type, person information; add person, update, add role,...
    2. Consumer listening on the queue and provisions to end points like legacy CTB? and LDAP. 
    3. Roadmap: ActiveMQ with CAMEL endpoints
    4. CAMEL have about 70+ components, we're using several of them.
    5. Changelog dB table / Event log will continue on, but be supplemented 
    6. Mix & match backend registries that we work with & see if the CAMEL; with OR after changelog gets created and rest could change; is that an interesting cleavage plane?
  3. Detailing the CIFER P&I three and six month work plan
    1. by January 31, 2013
      1. Use cases for demo solutions fully documented;
        1. UNC Improv provisioning
        2. Notre Dame provisioning
        3. PennState CPR provisioning
        4. Rutgers OR provisioning
        5. Clemson provisioning
        6. U Fl QuickReg Guest System
        7. UW-Madison PersonHub provisioning to O365 and to HR (Oracle/PS HCM)
        8. Duke U O365,...
        9. UC Davis
        10. ? Producing flat file batch reloads
        11. ? Downstream batch diff based provisioning
        12. ? Changelog processing model
      2. Toolkits identified
      3. P&I models documented and illustrated by reference to above
      4. Vetting emerging CIFER APIs against our P&I use cases
        1. NOTE: CIFER API calls are biweekly on Wednesdays at Noon Eastern, 9:00 am Pacific; the next call is November 14. 
        2. Same conference call line as this call, with access code 0121717#
        3. Do we mix in CAMEL and ActiveMQ with REST? Persistence would be the challenge. Some way to match the Clemson transport with back-end storage
    2. by April 30, 2013
      1. Demo solutions implemented and documented including recipes, tool choices and code snippets
      2. Detailed roadmap for P&I deliverables over following 12-18 months

NB: Omer Almatary and Muhammad Siddique will join a future CIFER-P&I call to detail Rutgers U approach to provisioning into Workforce.

Action Items:

[KeithH] Work with Clemson on detailing next steps

[RobC] Approach Omer, Muhammad, JimmyV about shared interest in ActiveMQ

  • No labels