wiki:TI12_Security/NDG/UseCases/BrowserClientAccessToAResource

Access to a Data Provider Resource via a Browser Client

Description

A user accesses a secured resource at an NDG site via a browser client.

Actors

  • User
  • Data Provider (A)
  • Site where user is registered (B)
  • Resource at A to be accessed
  • Client browser
  • A (Data Provider) Web Server
  • A (Data Provider) user credentials request interface
  • Login Interface B - where user logs in and from where credentials may be returned to the Data Provider user credentials request interface
  • Attribute Authority WS A (data provider)
  • Attribute Authority WS B - AA for where user is registered.
  • Session Manager WS A - data provider's Session Manager
  • Session Manager WS B - where user's session is held
  • Credential Wallet B - part of the user's session. It holds user's proxy certificate and caches Attribute Certificates

Assumptions

  • Sites A and B have NDG security infrastructure in place.
  • Site A trusts site B and has role mapping in place for A.

Triggers

Data Provider requests user identity credentials in order to access NDG secured resource.

Outcome

User is granted access to secured resource.

Normal Course

  1. User selects a resource from NDG data provider A web site.
  2. A's server side code checks the security constraints for that resource and determines that NDG security credentials are required.
  3. It displays A's user credentials request interface over a secure connection.
  4. The interface queries A's Attribute Authority WS to find out the list of NDG sites that A trusts. The information includes the names of trusted sites and the URIs for their site login pages. The interface gets A's Attribute Authority address from the secured resource's meta data.
  5. The interface displays the list of trusted sites for the user to choose where they wish to retrieve their credentials from.
  6. The user selects site B as they are registered there.
  7. The interface redirects the user's browser to site B's NDG enabled login interface.
  8. If the user has already authenticated there will be an NDG security session cookie present in site A's host domain. Redirect back to the user credentials interface at A. If A and B hosts are in different domains, include the session information in the URI so that it can set a new cookie in A's domain.
  9. If the user has not already authenticated at B, then display B's login interface.
  10. The user enters their username and pass-phrase.
  11. Login interface passes the credentials over HTTPS to Session Manager B
  12. B Session Manager authenticates the user, makes and holds a session for them and returns a cookie back to the login interface
  13. Login interfaces sets the security session cookie and redirects the user's browser back to the user credentials interface at A. If A and B hosts are in different domains, include the session information in the URI so that it can set a new cookie in A's domain.
  14. 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.
  15. Session Manager A checks the cookie, finds that the user's session is held at Session Manager B. IT forwards the request there.
  16. Session Manager B checks in the user's wallet for existing Attribute Certificates issued by Attribute Authority A
  17. If none are present it requests one from Attribute Authority A
  18. 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.
  19. Session Manager B checks it's wallet for an Attribute Certificate from one of these trusted sites.
  20. B is a trusted site and the wallet contains an Attribute Certificate issued by B.
  21. 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.
  22. The chosen Attribute Certificate is sent in a second request to Attribute Authority A in order to get access.
  23. 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.
  24. The mapped roles are returned in a mapped certificate to Session Manager B.
  25. 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.
  26. The Credentials Interface passes the mapped Attribute Certificate to the Gatekeeper WS controlling access to the resource at A.
  27. 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.