wiki:TI12_Security/DEWSHealthStreamPortalAccess2MetOfficeGeoserverUseCase

Version 5 (modified by pjkersha, 13 years ago) (diff)

--

Access to Geoserver Resource from the Health Stream Portal

Description

The steps required for a user of the Health Stream portal to access a secured resource from the MetOffice Geoserver.

Actors

  • User
  • Client browser
  • Health Stream Portal where user is registered (Portal)
  • Portal Web Server (PortalWebServer)
  • Portal login interface (PortalLogin) - where user logs in
  • Portal Attribute Authority WS (PortalAA) - AA for where user is registered.
  • Portal Session Manager WS (PortalSM) - where user's session is held
  • Credential Wallet (CredentialWallet) - part of the user's session held by the PortalSM. It holds the user's proxy certificate/private key and caches Attribute Certificates (ACs)
  • MetOffice (Data provider)
  • MetOfficeGatekeeper (MetOfficeGatekeeper)
  • MetOfficeGeoserver (MetOfficeGeoserver)
  • Resource at MetOffice Geoserver to be accessed
  • MetOffice Attribute Authority WS (!MetOfficeAA)

Assumptions

  • MetOffice and Health Stream Portal have NDG security infrastructure in place.
  • MetOffice trusts the Health Stream Portal and has role mapping in place for the Portal.

Triggers

A user accesses a link at the DEWS Health Stream portal requiring access to a secured resource on the MetOffice? Geoserver.

Outcome

User is granted access to secured resource.

Normal Course

  1. User selects a secured resource from the Health Stream portal web site.
  2. PortalWebServer server side code checks for the existence of a security session cookie.
  3. No security cookie is present so they are redirected to the Portal login page (PortalLogin).
  4. The user enters their username and pass-phrase at the PortalLogin over a HTTPS connection.
  5. The PortalLogin passes the credentials over HTTPS to the PortalSM.
  6. PortalSM authenticates the user, makes and holds a session for them and returns a cookie back to the PortalLogin
  7. PortalLogin sets the security session cookie.
  8. The Portal calls the PortalSM with getAttCert to ask it to retrieve an Attribute Certificate from the PortalAA.
  9. PortalAA accepts the request since the user is registered with the Portal and returns an Attribute Certificate.
  10. The PortalSM caches the Attribute Certificate returned in the user's CredentialWallet.
  11. The PortalSM calls the MetOfficeAA with a getAttCert request passing its portal Attribute Certificate.
  12. MetOfficeAA accepts the Portal Attribute Certificate as it is from a trusted site. It uses its role map to map the roles contained in the Portal Attribute Certificate to local roles understood by MetOfficeGeoserver.
  13. The mapped roles are returned in a mapped certificate to PortalSM.
  14. PortalSM adds the new mapped Attribute Certificate to the user's wallet and returns the Attribute Certificate to the Portal.
  15. The Portal passes the mapped Attribute Certificate to the MetOfficeGatekeeper with the Geoserver request.
  16. The MetOfficeGatekeeper checks the roles in the mapped Attribute Certificate against the role(s) controlling access to the resource. If they match, access to the resource can proceed.