The document proposes adding federated identity management to OpenStack to allow users to authenticate using existing credentials from an identity provider. This would simplify credential management for users and developers. It describes components like an OpenStack gateway that would handle authentication and attribute validation, mapping identities to local tenants and roles. Next steps discussed include a live demo, getting feedback, and incorporating this into a future OpenStack release.

1. Adding Federated Identity
Management to OpenStack
David Chadwick
University of Kent
Open Stack Summit
University of Kent 1
18/10/2012

2. 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
• 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 staff
– No need to register new users, replace lost or forgotten
credentials, remove old users
Open Stack Summit
University of Kent 2
18/10/2012

3. Limitations
• Still need a way to finely differentiate users for
authorisation purposes
• Still need to be able to ban abusive users
• Probably need to use a web browser for the
actual step of user authentication
• More steps involved in protocols, and in user
interface
• 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
Open Stack Summit
University of Kent 3
18/10/2012

4. Attribute
+ Authn
Attribute
DB
Authn
DB FIM Components
DB
Federation
IdP AA AS Directory
Service
RIS Credn
At AM CVS Validation
Ag Policy
OpenStack
User/ Gateway
Client
TIS TVS
Access
Control
Cloud Cloud Cloud
Authz Policy
Service
Provider 1
Open Stack Summit
Service
Provider 2
...
University of Kent
Service
Provider n
(PDP)
4
18/10/2012
Policy DB

5. 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
• OG – OpenStack Gateway (Currently the role played by
Keystone)
• PDP – Policy Decision Point
• RIS – Request Issuing Service
• TIS – Token Issuing Service
• TVS – Token Validation Service
Open Stack Summit
University of Kent 5
18/10/2012

6. Guiding Principles
• Keep it simple for CSPs
– Bulk of security done by OG (user authn and attribute validation)
• Each CSP keeps it existing tenants/accounts and roles for authz and trusts
OG to correctly issue them to users
– Are thousands of IdPs/AAs, millions of attributes so OG must map between these and
CSP tenants/roles
– Mapping must be configurable in OG, e.g. through policies or config files
• OG has a set of trust relationships with a set of external IdPs, ASs and AAs
– All IdP/AA issued attributes/roles must be globally identifiable so OG knows how to map
these into the local tenants/roles
• User knows which cloud service he wishes to use, so this is his first port of
call
– User does not need to know about OG. CSP can dynamically change OG. CSP can
dynamically change its role requirement policy
• Most IdPs rely on UN/PW so are open to phishing attacks
– Introduce an intelligent client which is not phishable. It performs a directory
lookup on the issuer in order to obtain its metadata and make a direct request
to it (research topic)
Open Stack Summit
University of Kent 6
18/10/2012

7. Single IdP, Simple Client
OG Internal Services
User Client CSP PDP Dir OG AM RIS CVS TIS TVS IDP
0 1
2
3
4
5
6 7
8
9
10
11
12 12
13
14
15
16 17
18
19
20
21
23 22
24 25
30 26
27
28
29 29
Open Stack Summit
University of Kent 7
18/10/2012

8. Next Steps
• Live Demo ?
• How to get public comment and feedback?
• How to incorporate this into future OpenStack
release ?
• Beta release is now available for testing and
feedback. Who would like a copy?
Open Stack Summit
University of Kent 8
18/10/2012

9. Step 0
C:Python27Scripts>python swift -F -A
http://persistence.kent.ac.uk:80/v2.0/ list textFiles
Ret
Open Stack Summit
University of Kent 9
18/10/2012

10. Step 6
C:Python27Scripts>python swift -F -A
http://persistence.kent.ac.uk:80/v2.0/ list textFiles
You have access to the following realm(s):
{ 0 } Kent Proxy Identity Service
{ 1 } Big Bank
Enter the number corresponding to the realm you
want to use:
Ret
Open Stack Summit
University of Kent 10
18/10/2012

11. Step 12
Open Stack Summit
18/10/2012
Ret
University of Kent 11

12. Step 19
C:Python27Scripts>python swift -F -A
http://persistence.kent.ac.uk:80/v2.0/ list textFiles
You have access to the following realm(s):
{ 0 } Kent Proxy Identity Service
{ 1 } Big Bank
Enter the number corresponding to the realm you
want to use: 1
You have access to the following tenant(s):
{ 0 } Visa User's Cloud Services
Enter the number corresponding to the tenant you
want to use:
Open Stack Summit Ret
University of Kent 12
18/10/2012

13. Step 29
C:Python27Scripts>python swift -F -A
http://persistence.kent.ac.uk:80/v2.0/ list textFiles
You have access to the following realm(s):
{ 0 } Kent Proxy Identity Service
{ 1 } Big Bank
Enter the number corresponding to the realm you want to use: 1
You have access to the following tenant(s):
{ 0 } Visa User's Cloud Services
Enter the number corresponding to the tenant you want to use: 0
August2012.txt
July2012.txt
September2012.txt
C:Python27Scripts>
Open Stack Summit
University of Kent 13
18/10/2012
Ret