vash interoperability of aai and grids placi flury, switch · infso-ri-031688 enabling grids for...

INFSO-RI-031688

Enabling Grids for E-sciencE - II

www.eu-egee.org

VASH Interoperability of AAI and Grids

Placi Flury, SWITCH

EuroCamp Stockholm 7-8 May 2008

Terena EuroCAMP Stockholm 7– 8 May 2008 2

Enabling Grids for E-sciencE

INFSO-RI-031688

• Ms. Shibboleth (profile)– friends:

thousands of usershundreds of resources

– language skills: SAML (natively browser-based)

– interests: access to more resources (grids could be very attractive)

• Mr. Grid (profile)– friends:

few users in academia (particularly liked by physicists) thousands of resources (CPU, storage)several institutions (most also known by Ms. Shibboleth)

– language skills: still learning SAML (understands X509) – interests:

easy access for more usersget/user information for authorization from authoritative sources outside of the grid universe

• Common interest: leverage of existing identity management and allow easy access to grid ‘resource’

A perfect couple?

We target at a KISS* solution



INFSO-RI-031688

Outline of presentation

• Interoperation– why interoperability between AAI and grids?– where’s the challenge

• Interoperability Shibboleth - Grid – easy grid access: Short Lived Certificates Service (SLCS)– more granular authorization and mapping: VASH– (Demo)

• What’s the future?– Secure Token Service

• Summary



INFSO-RI-031688

Why Interoperability between Grid and AAI?

For Shibboleth Federations

• Add grid resources to federation

For Users

• Simpler management of credentials

• Easy access to Grids

For Grids

• Add huge user base (campus)

For e-Science

• Unified user base

• Bring stake-holders together: NRENs & Grids



INFSO-RI-031688

What is meant by “interoperability”?

• Focus is on:– Interoperability (NO replacement for X.509) – Specific for EGEE-2 infrastructure (VOMS etc.)– Integrate, re-use, re-engineer existing code, write new code only

as needed

• Key Concepts:– Home institution of the user should be the Identity Provider

In contrast to issuing organization CA– Shibboleth attributes shall be used for certificates as well– But VO is still needed for (grid specific) attributes



INFSO-RI-031688

Challenges

• Different (concept of) identities:– Shibboleth:

user described by attributes (e.g. unique ID,name, affiliation, study field)one identity throughout the entire federation

– Grid:user identified by his X509 certificate (DN/CA) user privileges defined by VO membership and respective group and role (+ potential attributes)user gets new local identity at resource (local identity e.g. uid,gid)(pseudonymity identity)

• Different access mechanisms:browser-based (Shibboleth) vs command line based for most gridsauthN/Z with X509 proxy certificates + attribute certificates (AC), containing

VO info vs SAML assertionsX509 enrollment for large user bases



INFSO-RI-031688

Challenges (cont.)

• Compatibility– interoperability with existing/legacy systems– transparent

• Semantics: Federation attributes vs VO attributes– mixed VO and federation information. Interpretation of user

information depends on common understanding



INFSO-RI-031688

How to achieve interoperability• Start with something that doesn’t break existing

– 1. Easy access – 2. Consolidate data and not mechanisms

QuickTime™ and a decompressor

are needed to see this picture.

SLCS = Short Lived Credential Service VOMS = Virtual Organization Membership ServiceVASH = VOMS Attributes from Shibboleth UC = User CertificateAC = Attribute Certificate



INFSO-RI-031688

Easy grid access:SLCS

• Online CA issuing short-lived X.509 certificates based upon authentication at Shibboleth Identity Provider

• Shibboleth attributes used in DN

• Done in EGEE-II

• In production



INFSO-RI-031688

SLCS Operation

• For the user:• Command line: slcs-init --idp <providerId>• Part of gLite User Interface (gLite-UI 3.1)

(can also be installed independently)

• For the RA from web-based admin tool:• Can enable or disable individual users (only for his institution)• Requirements formulated in CP/CPS• Can obtain log information (audit)

• SWITCH: • Operates the service for the SWITCHaai federation



INFSO-RI-031688

Life without VASH

VO : switchsubject : /DC=ch/DC=switch/DC=slcs/O=Switch - Teleinformatikdienste fuer Lehre und Forschung/CN=Placi Flury C82EEB1Aissuer : /O=GRID-FR/C=CH/O=SWITCH/OU=MIDDLEWARE/CN=concordia.switch.chattribute : /switchattribute : /switch/production

• Example of proxy information without VASH



INFSO-RI-031688

More granular authorization: VASH

• VO information + IdP information:– more granular authorization decisions– potentially better treatment (e.g. mapping to higher priority queue)

• VASH = VOMS Attributes from Shibboleth– consolidates IdP and VO user data on the VOMS– performs identity mapping (Shibboleth Identity -> VOMS Identity)– maintains list of allowed Shibboleth attributes for grid – enforces of up-to-date Shibboleth attributes on VOMS– removes expired attributes from VOMS– helps SLCS users to register on VOMS– provides administration facilities– auditing (to a certain degree)



INFSO-RI-031688

•

Life with VASH

Note, steps 1-4 only required if Shibboleth attributes changed or are about to expire on VOMS.



INFSO-RI-031688

VASH in more detail



INFSO-RI-031688

[flury@aurora ~]$ voms-proxy-info -allsubject : /DC=ch/DC=switch/DC=slcs/O=Switch - Teleinformatikdienste fuer Lehre und Forschung/CN=Placi Flury C82EEB1A/CN=proxy[cut] …..=== VO switch extension information ===VO : switchsubject : /DC=ch/DC=switch/DC=slcs/O=Switch - Teleinformatikdienste fuer Lehre und Forschung/CN=Placi Flury C82EEB1Aissuer : /O=GRID-FR/C=CH/O=SWITCH/OU=MIDDLEWARE/CN=concordia.switch.chattribute : /switchattribute : /switch/productionattribute : city = Stockholm (switch)attribute : urn:mace:dir:attribute-def:eduPersonAffiliation = staff (switch)attribute : urn:mace:dir:attribute-def:givenName = Placi (switch)attribute : urn:mace:dir:attribute-def:mail = [email protected] (switch)attribute : urn:mace:dir:attribute-def:sn = Flury (switch)attribute : urn:mace:switch.ch:attribute-def:swissEduPersonUniqueID = [email protected] (switch)attribute : urn:mace:switch.ch:attribute-def:swissEduPersonHomeOrganization = switch.ch (switch)timeleft : 11:59:58[flury@aurora ~]$

Example Proxy Certificate from VASH

FQAN

GAs

GA: Generic VOMS Attribute. Notice, VOMS does not distinguish whether the GA is from Shibboleth or not



INFSO-RI-031688

Usage of Shibboleth attributes at grid resource

• Authorization Plugin (input)<AccessControlList>

<AccessControlRule><Attribute name=”swissEduPersonHomeOrganization">unizh.ch</Attribute><Attribute name=”eduPersonAffiliation">staff</Attribute>

</AccessControlRule></AccessControlList>

• Mapping Plugin (input)<MappingRules>

<MappingRule><Attribute name="urn:mace:switch.ch:attribute-def:swissEduPersonHomeOrganization"

displayName="home organization">switch.ch</Attribute><Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation"

displayName="affiliation"> staff </Attribute><Map account=".switch" group="groupA"/>

</MappingRule></MappingRules>



INFSO-RI-031688

Authorization Plugin (LCAS)

<AccessControlList><AccessControlRule>

<Attribute name= "urn:mace:switch.ch:attribute-def:swissEduPersonHomeOrganization"> switch.ch </Attribute>

</AccessControlRule></AccessControlList>

Plugin log:LCAS 0: lcas.mod-lcas_run_va(): authorization granted by plugin /opt/glite/lib/modules/lcas_userban.mod

LCAS 0: lcas_voms_attr - is_rule_match(): ACL rule(1) matchedLCAS 0: lcas.mod-lcas_run_va(): authorization granted by plugin /opt/glite/lib/modules/lcas_voms_attr.mod

ACL file:



INFSO-RI-031688

Mapping Plugin (LCMAPS)

Identity Mapping Rules

<MappingRules>[cut]<MappingRule>

<Attribute name="urn:mace:switch.ch:attribute-def:swissEduPersonHomeOrganization" displayName="home organization">switch.ch</Attribute>

<Attribute name= "urn:mace:dir:attribute-def:eduPersonAffiliation"displayName=”Affiliation"> staff </Attribute>

<FQAN>/switch/Role=NULL/Capability=NULL </FQAN><Map account=”.switch" group=”switchprio"/>

</MappingRule></MappingRules>

Plugin logLCMAPS 0: lcmaps.mod-runPlugin(): running plugin /opt/glite/lib/modules/lcmaps_voms_attr.modLCMAPS 0: lcmaps_voms_attr - get_mapping(): mapping rule(2) matched

[cut]LCMAPS 0: lcmaps_voms_attr - plugin_run: lcmaps_voms_attr plugin succeededLCMAPS 0: lcmaps.mod-runPlugin(): found plugin /opt/glite/lib/modules/lcmaps_posix_enf.modLCMAPS 0: lcmaps.mod-runPlugin(): running plugin /opt/glite/lib/modules/lcmaps_posix_enf.modLCMAPS 6: lcmaps_plugin_posix_enf-log_cred(): uid=18911(switch001):pgid=45005(switchprio):sgid=2689(switch)LCMAPS 0: lcmaps_plugin_posix_enf-plugin_run(): posix_enf plugin succeeded



INFSO-RI-031688

VASH Key Features

• transparent integration of Shibboleth attributes in Grid (as VOMS generic attributes)

• no changes on existing Grid code…just add plugins• decoupled administrative domains• from point of view of Shibboleth, VASH is just another

service (web resource)• identity mapping done by user (low admin. burden)• no IGTF certificates on Shibboleth IdP• no performance penalties• issues with presented solution:

– intermediate storage (on VOMS) of Shibboleth attributes – semantics of attributes still open issue– grid resources do not know whether attributes really came

from IdP



INFSO-RI-031688

What’s the future?

• Goal: Extend use of SAML in grids beyond what is already provided by EGEE-II (SLCS, VASH)

• Benefits:– (Average) User has no certificates anymore– Introduce SAML gently beyond phase 1 and 2, gain experience– Compatible with Shibboleth roadmap (2.0, 2.1) and WS-Trust

STS implementation– Options open for future

• Requires: A mean for service to transform a security tokens it has into a security token it needs



INFSO-RI-031688

Security Token Service

• WS-Trust defines mechanisms for brokering trust to an authority called Security Token Service (STS)

• The Security Token Service have a trust relationship with both the client and the service.



INFSO-RI-031688

Use Cases

• Grid: – Shibboleth user wants to access a Grid resource (e.g. WMS, File

Catalogue, Storage Element…)– He needs to obtains security token that the Grid services

understand (X.509)

• Non-browser based Shibboleth applications: – User agent contacts Shibboleth IdP with credential (e.g.

username, password)– User agent receives SAML assertion to be sent to a Shibboleth

SP



INFSO-RI-031688

Scenario: Issue a proxy X.509• User authenticates with his credential to a Shibboleth IdP STS and

receives a SAML security token• User requests a proxy X.509 from a Grid STS using the SAML token



INFSO-RI-031688

Summary & References

• Easy access for Shibboleth users with SLCS• Authorization and mapping decisions at Grid resources with

Shibboleth enhanced user information

• Implementation for gLite as EGEE-II project finished

• For more details on VASH and SLCS: http://www.switch.ch/grid/slcs

http://www.switch.ch/grid/vash

http://www.switch.ch/grid/slcs

http://www.switch.ch/grid/vash



INFSO-RI-031688

The End.

Thank you very much for your attention

Questions?



INFSO-RI-031688

Terminology

• Attributes in Shibboleth:– key-value pair– common semantics within federation

• Attributes on VOMS:– FQAN (fully qualified attribute name), syntax specifies the

‘semantics’:/<VO>/<subgroup>/Role=<role>

E.g. /switch , /switch/bio/Role=admin– Generic Attribute (GA)

Key-value attributesemantics not specifically defined (consensus within VO?)



INFSO-RI-031688

VASH user view (1/2)



INFSO-RI-031688

VASH user view (2/2)

QuickTime™ and a decompressor

are needed to see this picture.



INFSO-RI-031688

Shibboleth Attributes on VOMS

vash interoperability of aai and grids placi flury, switch · infso-ri-031688 enabling grids for...

Documents