Versions Compared

Old Version 2

changes.mady.by.user trscavo@idp.protectnetwork.org

Saved on

compared with

New Version 3

changes.mady.by.user trscavo@idp.protectnetwork.org

Saved on

Key

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

...

The myVocs and GridShib project teams are exploring ways to integrate their respective software products. See the topic MyVocsGridShibIntegration for more information about the proposed integration.

Basically, myVocs is a SAMLIdPProxy, a bridge between a federation of Shibboleth IdPs and a federation of Shibboleth SPs:

...

  1. A browser client requests a VO web resource protected by a VO SP. If a security context for the principal already exists at the VO SP, skip to step 18.
  2. The client is redirected to the VO !IdP (which is protected by a federation SP).
  3. The client makes a Shibboleth Shibboleth. AuthnRequest to the VO ! IdP. If a security context for the principal already exists at the VO !IdP, skip to step 12.
  4. The client is redirected to the federation !IdP (ignoring a possible interaction with the federation WAYF).
  5. The client makes a second Shibboleth Shibboleth. AuthnRequest to the SSO service at the federation ! IdP. If a security context for the principal does not exist at the federation ! IdP, the ! IdP identifies the principal (details omitted).
  6. The ! IdP updates security context for this principal, issues an authentication assertion, and returns an authentication response to the client.
  7. The client submits the authentication response to the assertion consumer service at the federation SP. The assertion consumer service validates the authentication assertion in the response and passes control to the attribute requester.
  8. The attribute requester queries the attribute authority at the federation !IdP.
  9. The attribute authority returns an attribute response to the attribute requester.
  10. The federation SP updates its security context for this principal and redirects the client to the VO !IdP.
  11. The client makes a Shibboleth Shibboleth . AuthnRequest to the VO !IdP, the same Shibboleth. AuthnRequest made at step 3.
  12. The VO ! IdP filters the attributes from the header of the request (by virtue of the attribute exchange in steps 8 and 9), persists these attributes to the VO database (if necessary), and returns an authentication response to the client.
  13. The client submits the authentication response to the assertion consumer service at the VO SP. The assertion consumer service validates the authentication assertion in the response and passes control to the attribute requester.
  14. The attribute requester queries the attribute authority at the VO !IdP.
  15. The attribute authority returns an attribute response to the attribute requester. Both federation attributes (persisted at step 12) and VO attributes are included in the response.
  16. The VO SP updates its security context for this principal and redirects the client to the VO resource.
  17. The client requests the VO resource, the same request issued at step 1.
  18. The resource filters the attributes from the header of the request (by virtue of the attribute exchange in steps 14 and 15), makes an access control decision, and returns the resource to the client.

Any number of webapps may be protected in this way. The topic OnBecomingVOSP describes the process of becoming a VO SP.

...