wiki:TI12_Security/DEWS/GatekeeperHandleRequest

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

--

Use Case: Geoserver Gatekeeper Handles a Request from a client

Description

The steps required for the Gatekeeper to handle a request for data from the Geoserver that it protects.

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

  • Incoming SOAP messages from the client are secured with WS-Security digital signature.
  • MetOffice trusts the Health Stream Portal and has role mapping in place for the Portal.

Triggers

A client makes a request to the Gatekeeper for data.

Outcome

Client is granted access to secured Geoserver data.

Normal Course

  1. Gatekeeper verifies the signature of the incoming SOAP message from the client.
  2. Gatekeeper parses the Attribute Certificate contained in the SOAP message and
  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 calls PortalSM connect WS operation passing the credentials over HTTPS.
  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 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 CredentialWallet and returns the Attribute Certificate to the Portal.
  15. The Portal passes the mapped Attribute Certificate to the MetOfficeGatekeeper web service along 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.