Adding Federated Identity Management to OpenStack

Transcription

1 Adding Federated Identity Management to OpenStack David Chadwick University of Kent 3 December 2012 University of Kent 1 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 ownthat 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 2 1

2 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 (authnand authz) from one or more identity providers to gain access to other sites (service providers) within the federation The authenticating IdPwill 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 3 December 2012 University of Kent 3 How Does FIM Work? Service Provider Trust Relationship Identity Provider 3 December 2012 University of Kent 4 2

3 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 3 December 2012 University of Kent 6 3

4 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 authnand attribute validation) Backwards Compatibility. Each CSP should keeps it existing tenants and roles for authzand 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 3 December 2012 University of Kent 8 4

5 Some Challenges IdPDiscovery Problem How does OpenStackknow which IdPthe user wants to use Nascarsolution: display a set of IdPicons 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 Attribute + Authn DB Attribute DB Authn DB FIM Components IdP AA AS AM RIS CVS Credn Validation Policy User/ Client Keystone TIS TVS Directory/ Service Catalog Cloud Service Provider 1 Cloud Service Provider 2... Cloud Service Provider n Authz (PDP) Access Control Policy 3 December 2012 University of Kent 10 Policy DB 5

6 Single IdP, Simple Client User Keystone Internal Services Client CSP PDP Dir KS AM RIS CVS TIS TVS IDP December 2012 University of Kent 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 3 December 2012 University of Kent 12 6

7 User Single IdP, Intelligent Client AtAg Keystone Internal Services Client CSP PDP Dir KS AM RIS CVS TIS TVS IDP on, as before 3 December 2012 University of Kent 13 AA using an AS, Intelligent Client Keystone Internal Services User AtAg Client CSP PDP Dir KS AM RIS CVS TIS TVS AA AS From 15, as before 3 December 2012 University of Kent 14 7

8 User AtAg Keystone Internal Services Client CSP PDP Dir KS AM RIS CVS AA2 AA1 AS 1 Attribute Aggregation with a federated AS 17. Same as AA using an AS , 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 OpenStackGateway (Currently the role played by Keystone) PDP Policy Decision Point RIS Request Issuing Service TIS Token Issuing Service TVS Token Validation Service 3 December 2012 University of Kent 16 8

9 Next Steps Build an Attribute Mapping Service that can be administered by each IdP administrator Incorporate a VOMS server (being done by Aerospace in the US) 3 December 2012 University of Kent 17 9