SoR->Registry

HR System (SAP) informs a person registry (Baylor) of a new hire, retrieving a unique identity handle (possibly new, possibly pre-existing)

University X

Messaging Bus

Camel, RabbitMQ

An agent custom-written for the SAP HR system places a "new hire" event in a message queue being consumed by the person registry's inbound data interface using Camel hooks for RabbitMQ. The PR removes the message from the queue, processes it through first an ID Match interface and then, as necessary, an identity minting interface, then places a unique identifier on a collection of message queues (via a similar Camel->RabbitMQ interface) for consumption by both the original requestor (SAP) and other interested parties

Develop (Baylor)

Brainstorm Items...

SoR->Registry, Registry->Consumer, Migration Into CIFER, Consumer<->AA

UNC ONYEN provisioning (New employee credential creation) (Registry->Consumer), UFL Guest System (SOR->Registry), Clemson (SoR->Registry->Consumers), Penn St. (CPR cases), Rutgers (SoR->OpenRegistry->LDAP),Duke use cases,Wisconsin use cases (classic provisioning), Scalable Privacy use cases (Keith - Consumer<->AA - "preference set support") - [app wants to retrieve preference information with privacy protection but without SAML assertions passing the data - AA + Policy managed by user + OpenID/OAuth-like access management], Grouper use case(s), Utah use case(s)

Site/Individual espousing the use case.

Direct API Thing, Full Batch Load, Incremental Batch Load, Changelog Consumer, Message Bus