The document discusses identity and access management (IAM) in OpenStack, focusing on the Keystone service. It provides an overview of Keystone and describes how it handles authentication, authorization, and identity management. It also discusses the different identity sources that Keystone supports, such as SQL, LDAP, and multiple backends. Authentication methods covered include password, token, and federated identity. Large scale deployments of Keystone are also described.

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

2. Agenda
● OpenStack
and
Keystone
Overview
● Iden6ty
Sources
● Authen6ca6on
● Iden6ty
Federa6on
● Access
Management
Model
in
OpenStack
● Future
Plans

3. OpenStack and Keystone: The Quick Overview!

4. OpenStack Overview
● OpenStack
is
a
cloud
opera6ng
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
Iden6ty
and
Access
Management
(IAM)
Service
○ Authen6ca6on
○ Authoriza6on
○ Audit
○ Iden6ty
○ OpenStack
Service
Discovery
● Supports
integra6on
with
a
variety
of
Iden6ty
Providers
● Pluggable
authen6ca6on
architecture
● Supports
mul6ple
API
Authoriza6on
Token
formats
● New
enhancements
include
support
for
standard
federa6on
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/iden6ty
Medium
● Single
datacenter
● Mul6ple
Keystone
instances
using
HAProxy
for
load
balancing
Large
● Several
OpenStack
deployments
spread
over
many
geographically
disperse
areas
● Mul6ple
Keystone
instances
using
HAProxy
for
load
balancing
and
SQL/LDAP
replica6on
to
keep
data
in
synchronized
Very
Large
/
Mul6ple
Organiza6ons
(Hybrid/Composite)
● Many
OpenStack
deployments
spread
over
many
geographically
disperse
areas
● Uses
Federated
Iden6ty
to
allow
near-­‐seamless
access
to
all
deployments
● Some
deployments
will
provide
specific
services
/
features

8. Identity Sources

9. SQL
● Users,
groups,
and
creden6als
are
managed
by
Keystone
● Se]ngs
for
connec6ng
to
a
database
are
handled
in
Keystone’s
config
file
● Essen6ally,
Keystone
is
ac6ng
as
an
Iden6ty
Provider
● Pros:
○ Easy
to
setup
○ Management
of
users
and
groups
through
OpenStack
APIs
● Cons:
○ Keystone
shouldn’t
be
an
Iden6ty
Provider
○ Weak
password
support
§ No
password
rota6on
§ No
password
recovery
§ No
password
enforcement
§ No
failed
login
a`empt
lockout
support
○ Most
enterprises
have
an
LDAP
server
that
they
want
to
use
○ Iden6ty
silo
-­‐
Yet
another
username
and
password
users
must
remember
Use
Case:
-­‐
Tes6ng
or
developing
with
OpenStack
-­‐
Saving
OpenStack
service
accounts

10. LDAP
● Keystone
accessing
LDAP
should
act
just
like
any
other
applica6on
● Keystone
opera6ons
performed
on
LDAP
○ User/Group
lookup
(search)
○ Authen6ca6on
of
users
(bind)
● What
rights
does
Keystone
need
in
LDAP?
○ Read
access
to
user/group
a`ributes
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
mul6ple
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
addi6onal
LDAP
backends
should
be
managed
by
their
own
domain
Use
Case:
-­‐
Preferred
approach
for
most
enterprises

12. Identity Provider (IdP)
● A
source
for
iden66es
(Internal
IdP,
Google,
Facebook,
Twi`er)
● Handles
authen6ca6on
and
provides
iden6ty
informa6on
● Usually
backed
by
LDAP,
but
could
be
something
else,
like
AD
(Ac6ve
Directory)
● Essen6ally,
sohware
that
abstracts
out
the
actual
backend
and
translates
user
a`ributes
to
a
standard
protocol
format
(SAML,
OpenID
Connect,
etc.)
● If
you’ve
ever
used
your
Gmail
account
to
sign
into
another
online
applica6on…
then
you’ve
used
Google
as
the
Iden6ty
Provider
and
the
other
applica6on
as
the
Service
Provider
Use
Case:
-­‐
Leverage
new
Federated
Iden6ty
-­‐
An
IdP
already
exists
-­‐
Non-­‐LDAP
iden6ty
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
ini6ally
logging
into
Keystone
or
se]ng
up
service
accounts
for
other
OpenStack
services
Token
Token
Password

15. Token
● Users
can
exchange
their
exis6ng
(valid)
token
for
a
newer
token
● Also
sa6sfies
the
case
where
a
user
can
receive
an
unscoped
token
(ini6ally),
and
exchange
that
for
a
scoped
token
● Used
by
federa6on
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
valida6on
Use
Case:
If
a
user
wants
to
start
a
VM,
what
is
the
full
flow?
1. Authen6cate
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
authoriza6on
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}/ac;on)
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,
iden6ty,
image,
orchestra6on,
etc

19. Access Management Model in OpenStack
How
to
determine
if
a
user
can
perform
an
ac6on?
● 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}/ac;on
definitions
targets rules

20. Identity Federation

21. Federated Identity
● Users
can
exist
in
an
iden6ty
store
that
is
not
accessible
by
Keystone,
or
is
owned
by
a
different
en6ty
● Keystone
federa6on
allows
for
users
iden6ty
to
be
provided
as
a
part
of
the
authen6ca6on
request
○ Iden6ty
info
is
provided
as
environment
variables
● Keystone
is
protocol
agnos6c,
all
federa6on
protocol
details
are
handled
by
Apache
HTTPD
modules
○ SAML
-­‐
mod_shib,
mod_auth_mellon
○ OpenID
Connect
-­‐
mod_auth_openidc
● Terminology
○ Iden6ty
Provider
(IdP)
■ Trusted
provider
of
iden6ty
informa6on
○ Service
Provider
(SP)
■ Service
that
consumes
iden6ty
informa6on
(Keystone)
○ Asser6on
■ Trusted
representa6on
of
iden6ty
a`ributes
issued
by
IdP
for
consump6on
by
SP
■ If
using
SAML,
the
asser6on
represents
iden6ty
a`ributes
■ If
using
OpenID
Connect,
the
asser6on
is
a
set
of
claims

22. Mapping Engine
● Groups
are
created
in
Keystone's
iden6ty
backend
for
the
purpose
of
role
assignment
○ Mapping
establishes
group
membership
● Federa6on
specific
auth
URL
is
used
to
obtain
an
unscoped
token
○ Simply
iden6fies
user
and
groups
● Unscoped
federa6on
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
Federa6on
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
agnos6c
(supports
SAML,
OpenID
Connect,
Kerberos,
etc.)
○ Keystone
s6ll
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
authen6cated
with
their
Iden6ty
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
● Federa6ng
Iden66es
from
one
deployment
to
another
○ Works
almost
iden6cally
to
the
normal
Federated
Iden6ty
Flow
Except
the
origina;ng
SAML
IdP
is
another
Keystone
○ Trust
rela6onship
between
each
deployment
must
be
explicitly
setup
○ Leverages
Iden6ty
Provider
Ini6ated
SAML
Flow:
● User
authen6cates
with
their
own
cloud
● Exchanges
token
for
an
asser6on
● Forwards
the
asser6on
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
IdenJty
Provider
One time setup performed by cloud admins
Local
Cloud
User

41. Future Plans

42. Future Plans
● MFA
-­‐
Rackspace
has
proposed
an
MFA
specifica6on
that
is
in
progress
○ Would
be
pluggable
so
vendors
can
implement
their
own
MFA
● Federated
Iden6ty
Enhancements
(polish
off
rough
edges
from
Federated
Iden6ty
Keynote)
○ Be`er
client
experience
○ Easier
mapping
rules
● Authoriza6on
Enforcement
(Tokenless
Auth)
○ Use
X509
instead
of
passwords
○ No
token
needed
(with
X509)
for
interac6ng
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
mul6ple
data
centers
and
con6nents.
This
session
will
cover
details
of
Keystone,
what
can
be
accomplished
with
it
today,
how
OpenStack
integrates
with
your
enterprise
iden6ty
solu6on,
federated
iden6ty
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
○ Iden6ty
API
vs
Keystone
○ Scale
of
Keystone
Deployments
(1
vm
to
1000s
of
physical
machines)
● Iden6ty
Sources
○ Direct
Connect
(SQL,
LDAP,
Mul6ple
Backends,
SSSD)
○ Iden6ty
Provider
(IdP)
○ Use
Cases
● Authen6ca6on
○ Password
○ Token
○ External
(Kerberos,
x509,
etc)
○ Mul6-­‐Factor
● Iden6ty
Federa6on
○ Federa6on
(SAML,
OpenID
Connect,
ABFAB,
etc)
○ Keystone2Keystone
Iden6ty
Federa6on
○ Web
Single
Sign-­‐On
● Access
Management
Model
in
OpenStack
○ RBAC
○ Authoriza6on
○ Endpoint
Valida6on
of
AuthZ
● Future
Plans
○ Enhancements
to
Direct
Iden6ty
Sources
○ Federated
Iden6ty
○ Authoriza6on
Enforcement
● Closing
statements

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

48. SSSD
● Available
in
a
future
release
of
OpenStack
as
an
Iden6ty
Source
● Iden6ty
informa6on
lookup
can
be
offloaded
to
the
underlying
plaxorm
using
SSSD
● Eliminates
the
complexity
of
LDAP
handling
within
Keystone
● SSSD
-­‐
System
Security
Services
Daemon
○ Provides
access
to
remove
authen6ca6on
and
iden6ty
sources
(FreeIPA,
Ac6ve
Directory,
LDAP)
○ Support
caching
for
high
performance
and
fault
tolerance
○ Supports
failover
for
fault
tolerance
○ Integrates
via
PAM,
NSS,
and
DBUS
● mod_lookup_iden6ty
○ Performs
lookup
of
iden6ty
a`ributes
from
SSSD
via
DBUS
○ Provides
iden6ty
a`ributes
as
environment
variables
to
web
applica6ons
● mod_auth_*
+
mod_lookup_iden6ty
looks
exactly
the
same
as
federa6on
from
the
perspec6ve
of
Keystone!

49. Multi-Factor Authentication
● When
knowing
a
password
is
not
enough
● These
factors
could
be:
○ knowledge
based
(ques6ons)
○ 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
iden6ty
driver
or
via
SSSD
(federated
LDAP)
○ HOTP/TOTP
tokens
(Yubikey,
FreeOTP,
Google
Authen6cator)
● Rackspace
has
proposed
an
MFA
specifica6on
that
is
in
progress
○ Would
be
pluggable
so
vendors
can
implement
their
own
MFA