1 / 20

Role Based VO Authorization Services

Role Based VO Authorization Services. Ian Fisk Gabriele Carcassi July 20, 2005. Definition. Role based VO authorization: an authorization decision based on an extended credential provided by the VO server that allows a user to have different sessions in which he obtains different privileges.

nadalia
Download Presentation

Role Based VO Authorization Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Role Based VO Authorization Services Ian Fisk Gabriele Carcassi July 20, 2005

  2. Definition • Role based VO authorization: an authorization decision based on an extended credential provided by the VO server that allows a user to have different sessions in which he obtains different privileges

  3. Use case • A VO compiles a list of users that can use data production resources • When acting as data production coordinator, the user gets a “token” from the VO, that states he is authorized to act in that role • The user presents that token to the site when submitting a job or initiating a file transfer • The services maps the user to a different account based on the role • The different account allows access to restricted resources or a different class of service (i.e. file access, higher queue priorities, special pool of machines, …)

  4. VOMS An example voms-proxy-init 0 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host The user, member of VO “foo”, wants to submit a job with a role “bar” to the gatekeeper of site “X”.

  5. VOMS An example voms-proxy-init 1 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host The user run “voms-proxy-init –voms foo:/foo/Role=bar”, to generate his VO authorized proxy.

  6. VOMS An example voms-proxy-init 2 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host Voms-proxy-init creates a normal user proxy, and then sends it to the foo VO VOMS server.

  7. VOMS An example voms-proxy-init 3 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host The VOMS server returns the VOMS proxy, signed by the VO, that authorizes the user to act as “bar”.

  8. VOMS An example voms-proxy-init 4 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host The user submits the job to site X

  9. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 5 grid3-user…txt gums-host The gatekeeper, through the globus call-out, delegates the PRIMA module to decide what local user account to should be used for the given GRID credential.

  10. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 6 grid3-user…txt gums-host Prima extracts the Proxy information and sends a message to asks GUMS which local account should be used. (The message is a SAML authorization request)

  11. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 7 grid3-user…txt gums-host GUMS consults its configuration, the local copy it keeps of the different database, and determines that the corresponding credential should be mapped to “foobar1”. GUMS returns a message, a SAML successful response with the obligation account=“foobar1”

  12. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 8 grid3-user…txt gums-host PRIMA interprets the response, and return the account “foobar1” to the gatekeeper.

  13. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 9 grid3-user…txt gums-host The gatekeeper sets the uid to “foobar1” and submits the job. Note: a cron jobs on the gatekeeper contact GUMS to retrieve the inverse map needed for accounting.

  14. Components: VOMS • A VO service (one per VO) that provides extended proxies with signed group and role membership • Vincenzo Ciaschini, INFN - Karoly Lorentey, et al • Part of OSG 0.2.1 distribution, used in production

  15. Components: PRIMA • The gatekeeper callout module that is able to contact a site Authorization service to retrieve the mapping • Markus Lorch, VT • Part of OSG 0.2.1 distribution, used in production

  16. Components: GUMS • A site Authorization service that manages site-wide mappings • Gabriele Carcassi, BNL • Part of OSG 0.2.1 distribution, used in production

  17. Components: VOMRS • A VO service that manages the VO Registration process, and feeds the list of currently approved members to VOMS • FNAL team • Used in production

  18. Storage AuthZ Execution site Gatekeeper GRAMgridFTP site GUMSServer PRIMA SRM/dCache StorageAuthorizationService gPLAZMA

  19. Components: Storage AuthZ • An authorization service that provides the extra authorization attributes required by dCache (contacts GUMS to retrieve the mapping) • Markus Lorch, VT • Prototype

  20. Components: gPLAZMA • The dCache Authorization infrastructure, which is able to contact the Storage Authorization Service • Abhishek Singh Rana, UCSD et al. • Distributed as part of dCache, Beta quality, in production at Fermi in a couple of months (probably less)

More Related