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


Access to Geoserver Resource from the Health Stream Portal


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


  • 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
  • Portal Credential Wallet (PortalCW) - part of the user's session. It holds user's proxy certificate and caches Attribute Certificates (ACs)
  • MetOffice (Data provider)
  • MetOffice Geoserver Gatekeeper (MetOfficeGatekeeper)
  • MetOffice Geoserver (MetOfficeGeoserver)
  • Resource at MetOffice Geoserver to be accessed
  • MetOffice Attribute Authority WS (!MetOfficeAA)


  • 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.


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


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.
  4. The user enters their username and pass-phrase at the login page (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 and redirects the user's browser back
  8. Credentials interface at A requires an Attribute Certificate from the user in order to get access. It calls Session Manager A to make the request passing cookie returned from domain B as ID and the URI for the Attribute Authority A.
  9. Session Manager A checks the cookie, finds that the user's session is held at Session Manager B. IT forwards the request there.
  10. Session Manager B checks in the user's wallet for existing Attribute Certificates issued by Attribute Authority A
  11. If none are present it requests one from Attribute Authority A
  12. Attribute Authority A denies the request as the user is not registered with site A. However, it also returns a list of the Attribute Authorities of trusted organisations.
  13. Session Manager B checks it's wallet for an Attribute Certificate from one of these trusted sites.
  14. B is a trusted site and the wallet contains an Attribute Certificate issued by B.
  15. At this point the credentials interface at B can prompt the user to see if they wish to use their B Attribute Certificate to gain access or if they would prefer to get an Attribute Certificate from one of the other trusted sites.
  16. The chosen Attribute Certificate is sent in a second request to Attribute Authority A in order to get access.
  17. Attribute Authority A accepts the B Attribute Certificate as it is from a trusted site. It uses its role map to map the roles contained in the B Attribute Certificate to local roles understood by site A.
  18. The mapped roles are returned in a mapped certificate to Session Manager B.
  19. Session Manager B adds the new mapped Attribute Certificate to the user's wallet and returns the Attribute Certificate to the Credentials interface at A.
  20. The Credentials Interface passes the mapped Attribute Certificate to the Gatekeeper WS controlling access to the resource at A.
  21. The Gatekeeper 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.