Page History

...

For the purposes of this document, user provisioning is defined to be the processes, both human and automated, that authorize (and de-authorize) people to use application systems, when those processes occur at times other than the start of an online session.   This is distinguished from application systems that use a "pure" single sign-on infrastructure (e.g., Shibboleth), authorizing anyone with a defined set of attributes that are provided at the start of a session.

The infrastructure described in this document will support the exchange of identity information from campus Identity and Access Management (IAM) systems to application systems, not the entire set of provisioning processes.   The Roles and Responsibilities section below describes where those other provisioning processes should be implemented.

...

• Snapshot. All identity information allowed by the attribute release policy will be transmitted to the application.
• Subscription. Identity information will be transmitted to the application as add, delete, and update transactions on an event-driven basis. The transactions sent will be those that have occurred (or will occur) since the last Snapshot, Subscription, or Change Log access.
• Change Log. All add, delete, and update transactions that have been generated since the last Snapshot, Subscription, or Change Log access will be transmitted.
• SSO Event. Identity information about the current user is transmitted at the start of a session. This is the existing Shibboleth access type.

Detailed design:

Image RemovedImage Added

Data Release and Governance

...

• Lots of momentum in industry
• Still immature
• Elegant in it's simplicity
• Wouldn't be able to deliver range if data needed without significant further development
• We could influence the course and pace if of it's maturation

SPML

• Not much uptake/active development in industry, with the exception of Oracle which relies heavily on SPML

...

For this project, the group has chosen SAML for the wire (the "mesh" in the Detailed Design diagram) protocol. This means that the IDMSTK and the SPTK will use SAML for communication. SAML was chosen because it is already used by Shibboleth, and with the advent of the Change Notify protocol, it was seen as the best option in terms of meshing with current infrastructure/processes.

Sample Request Flow

IDMS Toolkit

The IDMS Toolkit (IDMSTK) is a program which accepts requests from the various SPTKs (see SPTK section, below) for the purposes of account provisioning in a service provider. There is only one IDMSTK per institution, where there could be n SPTKs. The IDMSTK processes basic requests sent from the various SPTKs, and in turn, looks into the institution's local IDMS to fulfill the request. It is possible that not every institution's IDMS will be able to respond to all of the requests.

The IDMSTK will be able to answer the following types of requests:

• Get all of the changed IDs since the given time: getChangedSubjects(Time t)
• Get all changes for the given subject since the given time: getChangesForSubjectSinceTime(SubjectID id, Time t)
• Get current state of the given subject: getSubject(SubjectID id)
• Get the current state of everyone: getAll()

The requests outlined above will be performed over the wire using SAML (see reason for this in the Wire Protocols section, above).

The IDMSTK is comprised of the following:

...