Adding Federated Identity
Management to OpenStack
David Chadwick
University of Kent
3 December 2012 © University of Kent 1
3 December 2012 © University of Kent 2
Some Definitions
• What is Identity?
• A whole set of attributes that in combination uniquely characterise a person
– hair colour, sound of their voice, height, name, qualifications, past actions, reputation etc.
• Attribute – a property, quality or characteristic of an entity
• Identifier – a string used to uniquely identify an entity in a domain. Often used as login id or primary key in a database. A special type of attribute since it is usually the only one on its own that can uniquely identify an entity in a domain.
– X.500/LDAP DNs, IP addresses, DNS names, URIs, key IDs, login IDs, 128 bit random numbers are all identifiers.
• Attribute Assertion – a statement made by an authority that an entity has a particular attribute. An authority can be the entity itself or a (trusted) third party. • Attribute Certificate/Authorisation Credential – a cryptographically protected
(usually digitally signed) attribute assertion that can be validated
• Attribute Authority (AA) – an authoritative source for asserting attributes about entities
• Service Provider – an entity that provides a service to clients
• Identity Provider – an entity that provides an authentication service, and is often also an AA for a set of identity attributes of its users
3 December 2012 © University of Kent 3
So What is Federated Identity
Management ?
• A group of organisations that set up trust relationships which allow them to send assertions about users identities between themselves, in order to grant users access to their resources • A user can use his credentials (authn and authz) from one or
more identity providers to gain access to other sites (service providers) within the federation
• The authenticating IdP will usually provide the user with Single Sign On, but this may be transparent to the SP
• FIM systems typically require the following: data repositories, communications systems, provisioning systems, access
management systems, cryptographic systems, trusted third parties and legal agreements
How Does FIM Work?
3 December 2012 © University of Kent 4
Service Provider
Identity Provider Trust Relationship
Why Do It?
• Makes it easier for users
– Less credentials to remember/manage – Provides single sign on
• Makes it easier for system developers
– Don’t need to develop secure credential storage or authentication mechanisms and protocols
• Provides much more flexibility
– Allows any type of authentication mechanism to be easily incorporated since it is “out of scope” of the federation protocol and OpenStack code
• Can make it more secure
– Users can have one set of strong credentials, so less likely to share them, forget them etc.
– No longer a honeypot of credentials to be stolen by attackers
• Makes it easier for operations/administration staff
– No need to register new users, replace lost or forgotten credentials, remove old users
3 December 2012 © University of Kent 5
Identity Management in OpenStack Today
• Services are owned by tenants and users are assigned to tenants
– Many to many mapping tenants to services, tenants to users
• Keystone is the identity service which holds all the user account information (un/pw/tenants/roles)
• User information must be manually configured by OpenStack administrator or bulk loaded from corporate database
• In order to access an OpenStack service the user
1. Enters his un/pw, tenant and service request to the client 2. The client passes un/pw and tenant to Keystone
3. Keystone returns a scoped token
4. The client passes the scoped token to the service along with the service request
5. The service passes the scoped token to Keystone for validation 6. Keystone returns the users tenant and role(s)
7. The service uses the role(s) for authorisation via simple RBAC policy
Identity Management in OpenStack
3 December 2012 © University of Kent 7
Guiding Principles
• Keep it simple for Cloud Service Providers (CSPs)– Bulk of security should be done by Keystone (user authn and attribute validation)
• Backwards Compatibility. Each CSP should keeps it existing tenants and roles for authz and trusts Keystone to correctly issue them to users
• Keystone must have trust relationships with a set of external IdPs, ASs and AAs
– Need Credential Validation Service for validating these. All IdP/AA issued attributes/roles must be globally identifiable
• User knows which cloud service he wishes to use, so this should be his first port of call
– User should not need to know about Keystone. CSP can dynamically change Keystone. CSP can dynamically change its role requirement policy
– However this is not backwards compatible with existing mechanism so will be postponed for now
Some Challenges
• IdP Discovery Problem – How does OpenStack know which
IdP the user wants to use
– Nascar solution: display a set of IdP icons to user
– Shibboleth Where Are You From Service: lets user pick/search for his IdP
– Automatic selection: if SP knows, or global user IDs are used as in OpenID, EduRoam, ABFAB
– Decided to implement an IdP Directory Service
• Are thousands of IdPs/AAs and attributes but CSPs must
keep their existing tenants and roles
– Need an Attribute Mapping Service that must be configurable in Keystone, e.g. through policies or config files
• What Protocol to use – OpenID (Connect), SAML, Oauth etc.
– Decided to use a pluggable module, Request Issuing Service, so that protocol can be easily switched
3 December 2012 © University of Kent 9
Keystone CVS Credn Validation Policy TIS TVS AM RIS Cloud Service Provider 1 Cloud Service Provider 2 Cloud Service Provider n
. . .
Directory/ Service Catalog Authz (PDP) Access Control Policy User/ Client IdP AA AS Attribute DB Attribute + Authn DB Authn DB Policy DBFIM Components
Client CSP PDP Dir KS AM RIS CVS TIS TVS IDP Keystone Internal Services
2 5 User 6 8 9 10 11 12 13 14 15 17 19 20 21 22 23 24 25 26 27 28 29 30 31 32 4 12 1 31 3 7 16 18
Single IdP, Simple Client
3 December 2012 © University of Kent 11
Limitations
• Still need a way to finely differentiate users from one
IdP for authorisation purposes
• Still need to be able to ban abusive users
• Both of the above are a problem if you cannot
administer the IdP’s user account database
– Solution in Grid world is to introduce VOMS
• Does not currently support attribute aggregation
where user gets attributes from multiple IdPs/AAs
• Most federated identity management systems today
are open to phishing attacks from evil service
providers who redirect user to a clone IdP
– Use zero knowledge proof authn mechanism
– Have intelligent client that does not require redirection
and can determine itself how to contact the user’s IdP
Client CSP PDP Dir KS AM RIS CVS TIS TVS IDP 1 2 3 4 5 6 User 7 8 9 10 11 12 14 AtAg 13 15 on, as before 0
3 December 2012 © University of Kent 13
11
Client CSP PDP Dir KS AM RIS CVS TIS TVS AS Keystone Internal Services
1 2 3 4 6 User 7 8 9 10 11 12 13 14 15 16 17 18 19 From 15, as before 5
AA using an AS, Intelligent Client
AA AtAg
3 December 2012 © University of Kent 14
Client CSP PDP Dir KS AM RIS CVS AA2 AS Keystone Internal Services
1 User
18
20 Attribute Aggregation with a federated AS
AA1 AtAg 22 24 21 17. Same as AA using an AS 23 19
25, same as step 18 in AA using an AS
3 December 2012 © University of Kent 15
Acronyms
• AA – Attribute Authority. • AM – Attribute Mapper • AS – Authentication Service.
• AtAg – Intelligent component of the client (Attribute Aggregator)
• CSP – Cloud Service
• CVS – Credential Validation Service • Dir – Directory Service
• IDP – Identity Provider
• Keystone – OpenStack Gateway (Currently the role played by Keystone)
• PDP – Policy Decision Point • RIS – Request Issuing Service • TIS – Token Issuing Service • TVS – Token Validation Service
