1 / 10

Enhancing Grid Access with Shibboleth Attributes

Explore the integration of Shibboleth attributes for enhanced access control in the Grid environment. Discover key characteristics of Shibboleth and how it can improve user management on the Grid. Discuss challenges and solutions in leveraging existing identity management systems for seamless access to Grid resources.

qiana
Download Presentation

Enhancing Grid Access with Shibboleth Attributes

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. Shibboleth gJAF discussion Tele-meeting 22 Feb. 2007

  2. 4. SAML attributes 2.authN 3.handle 1. ‘access’ Shibboleth (short primer) Shibboleth gJAF tele-meeting

  3. 4. SAML attributes 2.authN 3.handle 1. ‘access’ Shibboleth Key Characteristics • concept of federation • large user base, few resources • single sign on Federation Shibboleth gJAF tele-meeting

  4. 4. SAML attributes 2.authN 3.handle 1. access GRID Grid, yet another Shib resource? • driving force: access to a highly attractive ‘resource’ (in particular for academia) • *but* the resource is protected by different concepts and mechanisms • Challenge: leverage existing identity management and allow easy access to the ‘grid resource’ Shibboleth gJAF tele-meeting

  5. Does Grid Care? • authN/authZ paradigms in Grid: • VO and X509 based (VOMS), • existing granularity level ends at group & role level • facility for more granularity exists =>VOMS feature of storing key-value data on individual basis (version 1.7.10 on) • Problem/open issue: • who is going to provide the information for key-value user data? • if VOMS is to handle all the user management at such a level, we’re back to the pre-Shibboleth age Shibboleth gJAF tele-meeting

  6. Grid meets Shibboleth • attributes that Shibboleth may provide for more granular authZ in the Grid • motivation to use Shibboleth attributes: • common understanding what they mean (“a rose is a rose is a rose”) • efforts to standardize attribute names with OIDs 4. SAML attributes 2.authN 3.handle 1. access GRID Shibboleth gJAF tele-meeting

  7. Coping with the ‘Grid resource’ • Problem: - Shibboleth federation concept not applicable for grid! (each grid component would need to become a federation member) • 2 Complementary Approaches • SLCS & mediator service VASH • (Switch’s phase 3…) Shibboleth gJAF tele-meeting

  8. Big Picture GRID for each VO and federation a Vash service/server Shibboleth gJAF tele-meeting

  9. Vash Service Shibboleth gJAF tele-meeting

  10. Grid authZ with Shibboleth • LCAS plugin (work in progress) • ACL xml file (no GACL as too limited, no XACML as no c impl.) • Example: <AccessControlList> <!-- simple rule example --> <AccessControlRule> <Attribute name="Unique ID"> 112358@switch.ch</Attribute> </AccessControlRule> <!-- AND rule example --> <AccessControlRule> <Attribute name="Shib-SwissEP-HomeOrganization">switch.ch</Attribute> <Attribute name="Shib-EP-Affiliation"> staff </Attribute> </AccessControlRule> <AccessControlRule> <Attribute name="Shib-SwissEP-HomeOrganization"> vho switchaai.ch</Attribute> </AccessControlRule> <AccessControlRule> <Attribute name="Shib-SwissEP-HomeOrganization">unizh.ch</Attribute> <Attribute name="Shib-EP-Affiliation">staff</Attribute> </AccessControlRule> </AccessControlList> Shibboleth gJAF tele-meeting

More Related