1 / 13

Authorisation in Grids

Authorisation in Grids. David Chadwick. Today. We enable people to perform tasks by adding them to our existing security databases Organisations do this all the time, they add customers, contractors etc to their internal security databases

wynona
Download Presentation

Authorisation in Grids

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. Authorisation in Grids David Chadwick

  2. Today • We enable people to perform tasks by adding them to our existing security databases • Organisations do this all the time, they add customers, contractors etc to their internal security databases • When I enrol for any web service, Amazon, E-Bay etc, I am added into all their systems • We are repeating this in Grids today, by adding everyone to the VO database • Its the "I need to control it all" mentality rather than the "trust and delegate" mentality

  3. Vision • We should be able to establish trust relationships between existing organisations (and their existing security databases) so that we dont need to add the new users to our system. • We can use their existing credentials and trust the issuing organisation to do it properly (otherwise we wont trust the issuer!) • Thus users, using their existing credentials, should be enabled to access new resources, within VOs and within other organisations by simply configuring trust relationships

  4. Is this too far fetched? • No, there are real live working examples of this today • Shopkeepers • Airport business lounges • UK Athens • Shibboleth

  5. Shopkeepers • A shop keeper wants to allow customers to purchase things in his shop on credit, without adding them to his database • He enters a trust relationship with Visa, and then anyone carrying an authentic and valid Visa card can purchase goods on credit in his shop • Note that Amex and Mastercard might be authentic but they are not valid (or trusted) since no trust relationship exists between the shopkeeper and Amex or Mastercard

  6. Airline Business Lounges • With my BMI gold card I can enter a United Airlines or Lufthansa business lounge, or in fact any Star Alliance business lounge • The Star Alliance partners have a trust relationship which says that they each trust the authentic and valid gold cards issued by the other partners • Note that bronze and silver cards are authentic but not valid. Similarly gold BA cards are authentic but not valid.

  7. Athens • Over 50 publishers, 200 user organisations (with over 1 million users) have trust relationships that allow a user in any UK university to access the online resources of a publisher • The publisher trusts the university to issue credentials to valid users

  8. Shibboleth • Has Identity Providers and Service Providers who enter trust relationships • The User's IdP has an authentication service provider and an attribute authority • The AA provides user attributes to the SP, who then provides services based on these electronic credentials • What is still lacking in Shibboleth is support for multiple distributed Attribute Authorities so that a user can provide credentials from multiple sources

  9. Enabling the Vision in Grids • A new service is needed, which I have termed the Credential Validation Service • The purpose of this service is to authenticate and validate a user's credentials, based on the policy rules (≡ trust relationships) that are configured into the system • Once the credentials have been validated, the valid attributes can be given to the PDP for it to make an access control decision (as now, e.g using XACML)

  10. Difference between STS and CVS • STS is a web services based Security Token Service. It performs credential issuing, credential validation, and credential translation services, and uses the WS-Trust protocol (although this is only a wrapper protocol that needs profiles to be defined) • CVS only needs to perform credential validation. No protocol is yet defined for it. • CVS needs to be policy driven, and there are no standard policy templates for this yet

  11. Possible Architectures1. PEP Intermediary PEP Validate Credentials Authz Decision Response Authz Decision Request Return valid attributes CVS PDP Policy Note. This is the architecture defined in the Open Group's AZN API standard, and implemented by PERMIS Policy

  12. Possible Architectures 2. XACML PIP PEP Note. This is the architecture implicitly supported in the GGF OGSA Authz draft Authz Decision Request Authz Decision Response Context Handler Policy Decision Point Authz Request Resource content Resource Authz Decision Attribute query Valid Attributes Policy Resource credentials Credential Validation Service Policy Environment credentials Subject credentials Policy Administration Point Subjects Environment

  13. Problems to be addressed by Authz group • 1. Agreeing the architecture(s) and protocol(s) - TOP PRIORITY, since OGSA Authz protocol is deficient • 2. Agreeing the policy rules that define the trust relationships - less important because these can be implementation dependent initially • 3. Linking the attributes from multiple AAs to the same user so that she can use them to gain access - pressing problem NOW e.g for GridShib • 4. Privacy and naming issues when there are multiple AAs - linked to above problem

More Related