Building IAM for OpenStack, presented at CIS (Cloud Identity Summit) 2015. Discuss Identity Sources, Authentication, Managing Access and Federating Identities

1. Building IAM for OpenStack
Steve Martinelli
Software Developer, IBM
Keystone Core

2. Agenda
● OpenStack and Keystone Overview
● Identity Sources
● Authentication
● Identity Federation
● Access Management Model in OpenStack
● Future Plans

3. OpenStack and Keystone: The Quick Overview!

4. OpenStack Overview
● OpenStack is a cloud operating system that controls large pools of compute, storage, and networking
resources throughout a datacenter, all managed through a rich set of APIs and a dashboard that gives
administrators control while empowering their users to provision resources through a web interface
● OpenStack’s goals are to support interoperability between cloud services and allow businesses to build
AWS-like cloud services in their own data centers
● Available as Free and Open Source under the Apache 2.0 license Keystone - provides authentication and
authorization for all the services.
Nova - provides virtual machines (VMs)
Swift - supports object storage.
Cinder - persistent block storage to VMs.
Glance - catalog and repository for virtual
disk images.
Horizon - Web-based interface for
services.
Neutron - networking-as-a-service
between interface devices

5. Lots of different companies using OpenStack
A lot of individuals and companies have contributed to making Keystone awesome (just to name a few…)

6. Keystone Overview
● OpenStack’s Identity and Access Management (IAM) Service
○ Authentication
○ Authorization
○ Audit
○ Identity
○ OpenStack Service Discovery
● Supports integration with a variety of Identity Providers
● Pluggable authentication architecture
● Supports multiple API Authorization Token formats
● New enhancements include support for standard federation protocols
● Access management for all OpenStack services

7. Scale of Keystone Deployments
Small
● Developer environments have OpenStack “all-in-one” deployments
● Devstack is used by most developers to spin up a deployment with compute/storage/networking/identity
Medium
● Single datacenter
● Multiple Keystone instances using HAProxy for load balancing
Large
● Several OpenStack deployments spread over many geographically disperse areas
● Multiple Keystone instances using HAProxy for load balancing and SQL/LDAP replication to keep data in
synchronized
Very Large / Multiple Organizations (Hybrid/Composite)
● Many OpenStack deployments spread over many geographically disperse areas
● Uses Federated Identity to allow near-seamless access to all deployments
● Some deployments will provide specific services / features

8. Identity Sources

9. SQL
● Users, groups, and credentials are managed by Keystone
● Settings for connecting to a database are handled in Keystone’s config file
● Essentially, Keystone is acting as an Identity Provider
● Pros:
○ Easy to setup
○ Management of users and groups through OpenStack APIs
● Cons:
○ Keystone shouldn’t be an Identity Provider
○ Weak password support
 No password rotation
 No password recovery
 No password enforcement
 No failed login attempt lockout support
○ Most enterprises have an LDAP server that they want to use
○ Identity silo - Yet another username and password users must remember
Use Case:
- Testing or developing
with OpenStack
- Saving OpenStack
service accounts

10. LDAP
● Keystone accessing LDAP should act just like any other application
● Keystone operations performed on LDAP
○ User/Group lookup (search)
○ Authentication of users (bind)
● What rights does Keystone need in LDAP?
○ Read access to user/group attributes defined in keystone.conf
○ Unprivileged account or anonymous is preferable
○ Access to password hashes is not needed
Use Case:
- It’s already in place in
your enterprise
- Able to create the
necessary service
accounts

11. Multiple Backends
● As of the Juno release, Keystone supports multiple backends
● One domain per backend
● The default domain must be the SQL backend, it is used to host service accounts
○ Ideally, the default domain should be normal users (LDAP), but this requires service accounts to
know how to use the v3 API
○ Support for services accounts outside the default domain will be available in a future release
● Any additional LDAP backends should be managed by their own domain
Use Case:
- Preferred approach
for most enterprises

12. Identity Provider (IdP)
● A source for identities (Internal IdP, Google, Facebook, Twitter)
● Handles authentication and provides identity information
● Usually backed by LDAP, but could be something else, like AD (Active Directory)
● Essentially, software that abstracts out the actual backend and translates user attributes to a standard
protocol format (SAML, OpenID Connect, etc.)
● If you’ve ever used your Gmail account to sign into another
online application… then you’ve used Google as the Identity
Provider and the other application as the Service Provider
Use Case:
- Leverage new
Federated Identity
- An IdP already exists
- Non-LDAP identity
source

13. Authentication

14. Password
● User provides their username and password
● Keystone returns a token that the user may use at other OpenStack services
● The token will eventually expire (configured in Keystone)
● Used for initially logging into Keystone or setting up service accounts for other OpenStack services
Token
Token
Password

15. Token
● Users can exchange their existing (valid) token for a newer token
● Also satisfies the case where a user can receive an unscoped token (initially), and exchange that for a
scoped token
● Used by federation client code
Token
Token
Token Supports
Kerberos too!

16. Access Management Model in OpenStack

17. Access Management Model in OpenStack
● Access is controlled by RBAC and endpoint validation
Use Case: If a user wants to start a VM, what is the full flow?
1. Authenticate with Keystone, specifies their user name, password, and project associated with the VM
2. The user gets back a token that is scoped to that project, it carries authorization data within it (a set of
roles the user has on that project)
NOTE: The role could have been granted at the user level or group level
1. The user makes a requests to the start server API (/v2/​{tenant_id}​/servers/​{server_id}​/action) with the
header "X-Auth-Token: <new_token>"
2. Depending on the policy set for the API, the user’s request will be rejected or successful

18. What does a Keystone token look like?
{
"token": {
"issued_at": "201406-10T20:55:16.806027Z",
"expires_at": "2014-06-10T2:55:16.806001Z",
"roles": [{
"id": "c703057be878458588961ce9a0ce686b",
"name": "admin"}
],
"project": {
"domain": { "id": "default",
"name": "Default" },
"id": "8538a3f13f9541b28c2620eb19065e45",
"name": "admin"
},
"user": {
"domain": { "id": "default",
"name": "Default" },
"id": "3ec3164f750146be97f21559ee4d9c51",
"name": "admin"
},
"catalog": [
{
"endpoints": [...],
"type": "identity",
"id": "bd73972c0e14fb69bae8ff76e112a90",
"name": "keystone"
}
]
}
}
<< Roles represents the roles that the user has
on the resource
<< Project represents the resource the user has
a role on. From the scope in the request
<< User represents the user that was issued the
token
<< Catalog describes the different services a
user may access, and their various endpoints
Services may be: compute, identity, image,
orchestration, etc

19. Access Management Model in OpenStack
How to determine if a user can perform an action?
● All APIs are documented in a policy.json file
● A policy file is broken up into Targets and Rules
● Targets map to a specific API
● Rules are a set of simple or complex checks
(RoleCheck, RuleCheck, OrCheck, AndCheck)
● For example…
compute:start maps to
/v2/​{tenant_id}​/servers/​{server_id}​/action
definitions
targets rules

20. Identity Federation

21. Federated Identity
● Users can exist in an identity store that is not accessible by Keystone, or is owned by a different entity
● Keystone federation allows for users identity to be provided as a part of the authentication request
○ Identity info is provided as environment variables
● Keystone is protocol agnostic, all federation protocol details are handled by Apache HTTPD modules
○ SAML - mod_shib, mod_auth_mellon
○ OpenID Connect - mod_auth_openidc
● Terminology
○ Identity Provider (IdP)
■ Trusted provider of identity information
○ Service Provider (SP)
■ Service that consumes identity information (Keystone)
○ Assertion
■ Trusted representation of identity attributes issued by IdP for consumption by SP
■ If using SAML, the assertion represents identity attributes
■ If using OpenID Connect, the assertion is a set of claims

22. Mapping Engine
● Groups are created in Keystone's identity backend for the purpose of role assignment
○ Mapping establishes group membership
● Federation specific auth URL is used to obtain an unscoped token
○ Simply identifies user and groups
● Unscoped federation token is used to obtain a scoped token
○ Contains group assigned roles

23. Federated Identity Flow

24. Federated Identity Flow

25. Federated Identity Flow

26. Federated Identity Flow

27. Federated Identity Flow

28. Single Sign-On
● The most demanded Federation feature in OpenStack is
finally here!
● Cross project work item between Keystone and Horizon.
○ Work items in three different projects: Keystone,
Horizon and django_openstack_auth
● Classic Web Single Sign-On experience in Horizon
○ Protocol agnostic (supports SAML, OpenID Connect,
Kerberos, etc.)
○ Keystone still acts as a Service Provider
○ Provides users with familiar branding
○ One less password for Keystone and Horizon to see

29. ● When the user loads Horizon, they can select the protocol desired, or use the old service accounts
Single Sign-On GUI Flow

30. ● Once a federated protocol is selected, the branded login page will appear
Single Sign-On GUI Flow

31. ● When authenticated with their Identity Provider, the user will be logged into Horizon
Single Sign-On GUI Flow

32. Single Sign-On Flow

33. Single Sign-On Flow

34. Single Sign-On Flow

35. Single Sign-On Flow

36. Single Sign-On Flow

37. Single Sign-On Flow

38. Single Sign-On Flow

39. Keystone 2 Keystone Federation
● Federating Identities from one deployment to another
○ Works almost identically to the normal Federated Identity Flow
Except the originating SAML IdP is another Keystone
○ Trust relationship between each deployment must be explicitly setup
○ Leverages Identity Provider Initiated SAML
Flow:
● User authenticates with their own cloud
● Exchanges token for an assertion
● Forwards the assertion to another cloud
● User now has a token for the remote cloud
Highlighted at the
Keynote of the last
OpenStack summit!

40. Keystone 2 Keystone Architecture
Keystone
Nova
Glance
Keystone
Nova
Glance
Local
Cloud
Remote
Cloud
A. Add Remote Cloud as a Service Provider
B. Add Local Cloud as an Identity Provider
One time setup performed by cloud admins
Local
Cloud
User

41. Future Plans

42. Future Plans
● MFA - Rackspace has proposed an MFA specification that is in progress
○ Would be pluggable so vendors can implement their own MFA
● Federated Identity Enhancements (polish off rough edges from Federated Identity Keynote)
○ Better client experience
○ Easier mapping rules
● Authorization Enforcement (Tokenless Auth)
○ Use X509 instead of passwords
○ No token needed (with X509) for interacting with Keystone CRUD interfaces
● Dynamic Policy
○ Rather than relying on the policy files themselves, this data should be stored in a database and
cached

43. Questions?

44. Backup Slides

45. Title and Abstract
Title: Building IAM for OpenStack
Abstract: Keystone is the IAM project for OpenStack, and as such has to handle many
different methods of deployment – On-Prem, Hybrid, Hosted – at many differing levels
of scale. Some deployments are no more than a VM used for development purposes,
while others are 100,000s of cores across multiple data centers and continents. This
session will cover details of Keystone, what can be accomplished with it today, how
OpenStack integrates with your enterprise identity solution, federated identity across
OpenStack deployments, the OpenStack model of access management today, and our
plans for the future.

46. not so pretty agenda to keep for slide titling (ICK!)
● Keystone in two minutes or less!
○ Keystone Overview
○ Identity API vs Keystone
○ Scale of Keystone Deployments (1 vm to 1000s of physical machines)
● Identity Sources
○ Direct Connect (SQL, LDAP, Multiple Backends, SSSD)
○ Identity Provider (IdP)
○ Use Cases
● Authentication
○ Password
○ Token
○ External (Kerberos, x509, etc)
○ Multi-Factor
● Identity Federation
○ Federation (SAML, OpenID Connect, ABFAB, etc)
○ Keystone2Keystone Identity Federation
○ Web Single Sign-On
● Access Management Model in OpenStack
○ RBAC
○ Authorization
○ Endpoint Validation of AuthZ
● Future Plans
○ Enhancements to Direct Identity Sources
○ Federated Identity
○ Authorization Enforcement
● Closing statements

47. Keystone Auth Token Middleware
● A common authentication protocol used between OpenStack projects
● Added to the paste pipeline of other projects

48. SSSD
● Available in a future release of OpenStack as an Identity Source
● Identity information lookup can be offloaded to the underlying platform using SSSD
● Eliminates the complexity of LDAP handling within Keystone
● SSSD - System Security Services Daemon
○ Provides access to remove authentication and identity sources (FreeIPA, Active
Directory, LDAP)
○ Support caching for high performance and fault tolerance
○ Supports failover for fault tolerance
○ Integrates via PAM, NSS, and DBUS
● mod_lookup_identity
○ Performs lookup of identity attributes from SSSD via DBUS
○ Provides identity attributes as environment variables to web applications
● mod_auth_* + mod_lookup_identity looks exactly the same as federation from the
perspective of Keystone!

49. Multi-Factor Authentication
● When knowing a password is not enough
● These factors could be:
○ knowledge based (questions)
○ possession based (security tokens, text messages)
○ inherence based (biometrics)
● FreeIPA has support for (One Time Password) OTP
○ Keystone can work with it via it’s LDAP identity driver or via SSSD (federated LDAP)
○ HOTP/TOTP tokens (Yubikey, FreeOTP, Google Authenticator)
● Rackspace has proposed an MFA specification that is in progress
○ Would be pluggable so vendors can implement their own MFA