ABFAB and OpenStack (in the Cloud)
David W Chadwick
University of Kent
Authentication in OpenStack
Trust
Relationship Keystone
Federated Authn with External IdPs
Trust
Relationship External IdP
ABFAB – SAML EAP Profile
Picture courtesy of BeSTGRID University of Auckland, NZ
Trust - an Indispensable Component of
FIM
• Trust in Authentication
– SPs must have a list of trusted authenticating authorities (IdPs, CAs etc.)
– SPs might have different mechanisms for this e.g. PKI to authenticate services and IdPs to authenticate end users
• Trust in Identification
– SPs must have a list of which trusted authorities are trusted to issue which identity attributes (types and values)
• Trust in Authorization
– SPs may want a set of locally understood authorization
attributes so will need attribute mapping rules that map from externally issued identity attributes to local authz attributes – SPs may want details of trusted external PDPs that will make
Key Features of Protocol Independent
FIM
• Modular Design
• Most functionality is provided by protocol independent code we added to Keystone
– Trusted IdP Policy – says which IdPs are trusted and which protocol each speaks
– Attribute Issuing Policy - says which IdPs are trusted to issue which identity attributes to users
– Attribute Mapping Policy - maps from IdP issued identity attributes into Keystone’s internal roles, projects and domains
• Protocol plug-in modules handle the Protocol Specific Features of federated login
– IdP Request preparation
– idP Protocol negotiation (optional) – IdP Response verification
FIM Protocol Module Output
• Federation wide Unique ID of end user e.g.
uid@idp
• Set of {Set of user identity attributes and
name of IdP that asserted them}
– Caters for future attribute aggregation
– LoA can be included as an identity attribute
Problem 1 – User Access Rights
• Not all users from one IdP should have the same access rights at an SP (e.g. OpenStack cloud)
• Different users from different IdPs may have the same access rights at an SP
• Solution 1. Give different users different identity attributes
– By updating the IdP
• Solution 2. Create a Virtual Organisation (VO) where different users from different IdPs may have the same identity attributes (or roles)
– Requires updating the IdPs or creating a VO service
• Solution 3. Add attribute mappings at the SP based on the user’s unique federation ID and identity attributes
Problem 2 – Updating the IdP Asserted
Attributes
• IdPs will not assert the attributes that SPs need
• Organisational IdPs typically store user’s attributes in
corporate LDAP servers, and these are fixed for use by the organisation
• Its very difficult (almost impossible?) for SPs to get the specific attributes they need for authz to be added to corporate LDAP servers
• Federated Solution – standardise a set of user identity attributes that all IdPs will issue and all SPs will consume e.g. EduPerson schema
• Grid Solution - the Virtual Organisation Management Service (VOMS) that allows a VO administrator to give tailored roles to VO users (from different organisations)
What About ABFAB Communities of
Interest?
• A CoI is a group of SPs and IdPs that have
agreed to cooperate to provide access to a
specific set of services only to those users
within a particular community
• CoIs can be layered on top of the base Trust
Router infrastructure to allow selected access
to IdPs that have joined a specific group
CoIs vs. VOs
• A set of IdPs and SPs• that co-operate to provide access to a specific set of services
• only to those users within a particular community
• CoI is at the IdP level so it is unclear if a subset of an
IdP’s users are in the CoI • CoI cannot be established
without IdP involvement
• A set of users
• from different organisations • that co-operate to share
resources
• for a common purpose
• Explicit that only a subset of users from an organisation (IdP) are in the VO
• VO needs to be established without IdP involvement
VO Solutions for OpenStack Cloud
• At least two different designs for this
• Have an external VO management system
(VOMS)
– Modify Keystone pipeline to aggregate attributes
from this
• Integrate VO management into Keystone
– Since Keystone already assigns roles/projects to
users or groups, extend its capabilities to assign
them to VO members, by mapping IdP asserted
attributes into a Keystone groups (=VO roles)
External VOMS
• The Keystone project concept extended to VO projects
– Project names starting with "VO." are VO projects
• Keystone and Swift clients and servers modified to
demonstrate the management of container access using VO roles Cloud A Keystone Cloud C Cloud B Keystone
The VOMS manages info for multiple VOs • Members
• Roles
VO 1 VO Admin
Swift Swift Swift
List Upload Download
Adding a vo_auth Stage to the Keystone
Command Pipeline
• All OpenStack services are designed with a configurable command pipeline
• When vo_auth sees a project name with the “VO.” prefix, it consults the VOMS
– Verifies user’s VO membership
– Returns member’s VO role and other sites participating in this VO
Request Response Token Auth VO Auth Admin Token Auth XML Body JSON Body Keystone Service VOMS Admin VOMS VO AdminVO Admin VO Admin Sites Roles Members
vo member
KeyVOMS Client
KeyVOMS Architecture Diagram
KeyVOMS VO … VO Foo Service Catalog Service Endpoint VO Resource Provider Endpoint VO PEP Service eg. SWIFT voms_admin KeyVOMS Client authenticate vo credentials w/ service catalog request reply validate validated register vo_admin KeyVOMS Client vo_site_admin KeyVOMS Client
Fe
Integrating VO Management into Keystone
• Use the federation attribute mapping service to form VO roles/groups
IDP 1 IDP 2 User 1 User 2 OpenStack Some VO Keystone Attribute Mapping Keystone Groups Id Atts A Federation
