Skip to end of metadata
Go to start of metadata

Tracked by JIRA-62.


Allow for validation of External Identity Credentials from trusted identity providers (IdPs), and the binding of the identity represented by those credentials to a new or existing OOI identity. This allows for subsequent authentication by the user with the external credentials to receive an OOI Identity Credential from an OOI Authentication Service. The Registration Services manages a set of bindings between OOI Identities and External Identities, which are maintained in a Principal Registry.

 The Registration Service must allow for registration of identities as asserted through the InCommon federation. Part of this design will be to document how OOI can interoperate with the CILogon Serviceto achieve use of InCommon IdPs.  This design covers how thick clients with register via CILogon to OOI.

Use Cases

New OOI User: A new OOI user who has not previously registered with OOI visits an OOI Web Portal. The Web Portal requests a credential from the CI-Logon service, which provides that credential based on authentication of the user via the user's home IdP in InCoomon. The Web Portal presents that credential to the Registration Service. The Registration Service validates the credential and generates an OOI Identity for the user. The binding between the External Identity from the CI-Logon credential and the OOI Identity is stored as state for later use by the Authentication Service in the Principal Registry.

Existing OOI User with Additional Identity: An existing OOI user who has previously registered an external identity to an OOI Identity now presents an Identity Credential representing a different external identity (e.g. from a second institution due to an organizational change on the user's part) along with a request to bind this new external identity to their existing OOI Identity to allow them to continue to maintain their previously established relationships within OOI. The process occurs identically as with the case of a New OOI User. On successful authentication of the new External Identity and the existing OOI Identity, a new binding between the two is placed into the Principal Registry.


In no particular order:

  1. The Registration Service must be able to validate External Identity Credentials
  2. The Registration Service must be able to map a user's External Identity to an OOI Identity based on state previously created by the Registration Service.
  3. The Registration Service must not accept External Identity Credentials from Identity Providers that it does not trust.
  4. The Registration Service must be able to issue OOI Identity Credentials that are trusted by Service Providers. This implies a well-managed service with private cryptographic keys.
  5. The Registration Service must be able to generate new OOI Identities that are guaranteed to be unique.
  6. The Registration Service must have the ability to create entries in the Principal Register.
  7. The Principal Registry must store state in a secure manner such that the bindings cannot be tampered with by unauthorized entities.
  8. There must exist an administrative interface to the bindings to allow authorized operators to manipulate them to handle exceptional situations (e.g. manually establishing a binding after out-of-band vetting of a user).
  9. A user must be able to undo a binding on the user's request.
  10. There must exist a mechanism for authorized operators or services to temporarily disable a binding in the event the user's External Identity is suspected or known to have been compromised.
  11. For binding an External Identity to an existing OOI Identity, the Registration Service must require proof that the client is authoritative for the existing OOI identity (e.g. they must authenticate in such a manner to prove that identity represents them or demonstrate sufficient administrative permissions).


In no particular order:

  1.  There must exist an administrative method for managing the External IdPs that the Registration Service trusts (perhaps shared with the Authentication Service).
  2. The Registration Service must be able to receive messages from users who are not yet registered with the rest of the COI infrastructure.


In no particular order:

  1. While there is no reason to make bindings of External to OOI Identities public, they are not particularly private either.

Conceptual Model

  1. User initiates registration by directing their web browser to an OOI Web Portal. The OOI Web Portal directs the user's browser to the CI-Logon service with a request to receive an delegated credential.
  2. The CI-Logon service, acting in the role of a Shibboleth service provider, redirects the user's browser to their identity provider (IdP).
  3. The IdP authenticates the user and redirect the user's browser back to the CILogon service, passing a SAML authentication assertion in the process.
  4. The CI-Logon service consumes the SAML assertion and issues an X.509 credential for the user to the OOI Web Portal.
  5. The CI-Logon service redirect the user's browser back to the OOI Web Portal.
  6. The OOI Web Portal presents the X.509 credential to the OOI Registration Service, which validates the credential, generates an OOI identity for the user and records that mapping in the Principal Registry. The Registration services returns an indication of success to the Web Portal.
  7. The Web Portal indicates successful registration to the user.

Technology Choices

  • The CI-Logon service will use Shibboleth to authentication the user through InCommon.
  • The CI-Logon service will issue X.509 end-entity credentials that conform to the IGTF Short-lived Certificate Service format.
  • The CI-Logon service will utilize OAuth to delegate the X.509 credential to the OOI Web Protal.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.