Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

LIGO COmanage Deployment Architecture

Gliffy Diagram
sizeL
nameligo-comanage-idm
Gliffy Diagram
sizeL
nameligo-cmp-identities

A MyLIGO/COmanage enrollment flow begins much as any other enrollment flow would. The enrollment flows require authentication so COmanage will redirect the user to the protected authentication page. With a standard deployment the user then sees a discovery page. This discovery page is customized so that it allows a user to pick from an existing identity and IdP or choose something like "create a new LIGO identity". If the user chooses to create a new LIGO identity then control is passed to the LIGO IdMS.

...

  • Can the IdMS just be another COmanage instance that has one flow for one "CO" and a special plugin or two? Note that it would not be the main MyLIGO/COmanage deployment.
    • Alternately, could the IdMS be implemented as an ID Match Service, with IdP of Last Resort plugins on the blue COmanage instances for credential management?
  • Can we leverage the Shibboleth Native SP backdoor functionality to do the handoff of the SAML assertion back to the MyLIGO/COmanage, so that it can consume the new organizational identity information that way? If we use the artifact back door then the IdMS would have to run on the same server box, but if we use the external authentication handler back door then it does not, and that is likely to be less confusing.