CIS14: Authorization: It's What's for Dessert

nmelbournensydneynsantacruz
www.viewds.com
n
e
w
Cookies and Hash: Basic
Identity and Access
Management Recipes
Authorization
Gil Kirkpatrick
gil.kirkpatrick@viewds.com

Copyright © 2014 ViewDS Identity Solutions
www.viewds.co
m
2

h#p://www.twistedoak.com/assets/client/File/chix/mary-‐jean-‐stclaire-‐Take-‐a-‐Chicken-‐to-‐Dinner-‐Tahoefull.jpg

www.viewds.co
m
Ingredient #0
3
No f*cking
passwords!

www.viewds.co
m
Ingredient #1
4
§ Develop your identity strategy starting
with your authorization and audit
requirements
§  Identify your most critical/sensitive data,
applications, and apis
§  What attributes do you need to decide who
is allowed to do what?
§  Where do those attributes come from?
§  How do you trust those attributes?
§  What is their lifecycle?
§  Who owns them?

www.viewds.co
m
Ingredient #2
5
§ Separate
authorization code
from the application
§ Manageability
§ Auditability
§ Security
§ Maintainability
§ Convenience
§ Efficiency

www.viewds.co
m
Externalizing Identity and Access
Management
IdenBty
LDAP directories
Cloud identity stores
AuthenBcaBon

Kerberos
SAML
OpenID Connect
Audit
Syslog
Windows event log
AuthorizaBon

XACML
OAuth 2
UMA

www.viewds.co
m
Ingredient #3
7
§ Have resource
owners define
authorization policy
§ Otherwise you get
Surprise du Chef
§ App devs and IT can’t
say what the
authorization policy
should be

www.viewds.co
m
Ingredient #4
8
§ Authorization policy,
not authorization code
§ Remove developers
from the authZ policy
loop
§ Give resource owners
the tools to manage
who gets access to
their stuff

www.viewds.co
m
Ingredient #5
9
§ Authorization has to be
fast and scalable
§ Mobile friendly
§ Web friendly
§ API friendly

www.viewds.co
m
Ingredient #6
10
§ Accommodate different
authorization models
§  User consent
§  Role-based Access Control
(RBAC)
§  Attribute-based Access Control
(ABAC)
§  Context-based Access Control
(CBAC)

www.viewds.co
m
Authorization Technologies
11
XACMLOAuth 2 UMA

www.viewds.co
m
OAuth 2
§ The motivation – eliminate the “Password Anti-Pattern” on the
web
§  Giving my FB password to Twitter so my tweets show up on my
timeline
§  Giving my FB password to Instagram so my photos show up on my
timeline
§  Giving my FB pass…. You get the idea
§ Answers the question “How to I allow this program I am using
controlled access to my stuff?”
§  Authorizing an application, used by the resource owner
§  Substantially different scenario than XACML

www.viewds.co
m
The Fundamental Idea
§ Instead of giving my FB password to Twitter I will make FB give
Twitter a token
§ Twitter can use the token instead of my password
§ The token will only let Twitter do certain things (scope) that I say
it can do, like access my pictures
§ The token only works for a certain amount of time in case it gets
stolen so Twitter has to periodically renew the token

www.viewds.co
m
Canonical OAuth2 Roles
15
Resource Owner
(RO)
Client
Authorization
Server (AS)
Resource Server
(RS)
Entity that can
make
authorization
decisions about
a resource
Program that needs
to access a
protected resource
on behalf of the
resource owner
Program that issues
tokens after
authenticating the
owner and getting
authorization
Server that
implements the
protected resource

www.viewds.co
m
OAuth2 Tokens
16
Access
Access token – presented
to the resource server to get
access to a particular scope
AuthZ
Grant

AuthZ grant – Represents
the owners consent to
access with a particular
scope
Refres
h
Refresh token - Used to
generate another access
token without requiring the
resource owner to reauthorize
the request

www.viewds.co
m
17
Canonical OAuth2 Flow
AuthZ
Request
AuthZ
Grant
AuthZ
Grant
Access
Token
(Refresh
Token)
Refresh
Token
Protected
Resource
Access
Token
Protected
Resource
Access
Token
Access
Token
Access
Token
Protected
Resource
Authenticate

www.viewds.co
m
Grant: Authorization Code
18
Notes:
•  Client pre-registers
return URI and
obtains credentials
from AS
•  Client
authenticates with
AS when
redeeming access
code
•  Access token
optionally includes
a refresh token
3
AuthZ
request
5
AuthZ
Grant
4
AuthN/AuthZ
6
AuthZ
Grant
7
Access
Token
1
Access
with
no
token
2
Access
denied
10
Protected
resource
8
Access
with
token
9
Validate
token

www.viewds.co
m
19
Grant: Implicit
Notes:
1.  Client pre-registers
return URI and obtains
an identifier
2.  Client does not
authenticate with AS
3.  Client is typically
supported by
Javascript running in
browser to parse out
token
4.  Refresh tokens are not
supported
3
AuthZ
request
4
AuthN/AuthZ
5
Access
Token
1
Access
with
no
token
2
Access
denied
7
Protected
resource
6
Access
with
token
JS

www.viewds.co
m
20
Grant: Client
Credentials
3
AuthZ
request
4
Access
Token
1
Access
with
no
token
2
Access
denied
6
Protected
resource
5
Access
with
token
Notes:
1.  No resource owner
involvement in
authorization flow
2.  Client authenticates
with AS
3.  Authorization policy
determined by prior
configuration
4.  Refresh tokens are not
supported

www.viewds.co
m
21
Grant: Resource
Owner Credentials
4
AuthZ
request
3
Username
and

password
5
Access
Token
1
Access
with
no
token
2
Access
denied
7
Protected
resource
6
Access
with
token
Notes:
1.  Resource owner
provides resource
credentials to client
2.  Client authenticates
with AS and provides
RO’s credentials
3.  Refresh tokens are
supported

www.viewds.co
m
Scopes
22

www.viewds.co
m
Scopes
§ What they are
§  Set of space-delimited strings
§ What they mean
§  ACL? Permission? Claims? Policy identifier? Operation?
§ Problem
§  Creates coupling between authorization server, resource server, and
client application
23

www.viewds.co
m
OAuth 2
Pros
§ Externalizes authZ from
application
§ Integrates user authentication,
app authorization and user
consent
§ Fits well with web architecture
§ Easy-ish to implement
§ Performance should be
excellent
Cons
§ Policies? We don’t need no
stinkin’ policies.
§ Deprovisioning timing subject to
token lifetime constraints
§ Design of scopes is left to the
reader
§  Coupling between client, AS
and RS
§ Not really oriented to enterprise
scenarios, but…
24

www.viewds.co
m
Architectural Differences between Oauth
and XACML
§  In Oauth and UMA, you authz once to get a token, then use the token for many transactions
§  Efficient
§  But unauthorization is not immediate and depends on token lifetime
§  Makes contextual authorization problematic
§  In XACML, the PDP evaluates every single transaction
§  Relatively inefficient, promotes complexity with caching, etc.
§  But you can deaut
§  In Oauth, the authorization process happens in two places: the AS and the RS
§  In XACML the AS makes the authorization decision
§  In UMA you
§  Client, AS, and RS all have to have a common understanding of scopes, and scopes are left to the reader
§  An unfortunate coupling between components that should evolve separately
§  In XACML, RS and AS work at arm’s length
§  The RS provides a minimal set of attributes to identify the policy
§  The Context Handler fills in the blanks
§  The PDP says yes or no
25

~
}
www.viewds.co
m
XACML is dead.
Andras Cser, Forrester May 2013
http://blogs.forrester.com/andras_cser/13-05-07-xacml_is_dead
27

~
}
www.viewds.co
m
The rumours of XACML’s death
are greatly exaggerated.
Dave Wilson, ViewDS 2013
With a tip of the hat to Samuel Clemens aka Mark Twain

~
}
www.viewds.co
m
XACML isn’t dead, it just smells
funny.
Gil Kirkpatrick, ViewDS 2014
With a tip of the hat to Frank Zappa

www.viewds.co
m
XACML
§ eXtensible Access Control Markup Language
§ Architecture for application authorization
§ Standardized XML-based policy language
§  Attribute-based
§  Fine-grained
§  Extensible
§ Standardized authorization request protocols
§  SOAPy
§  RESTful
§ Programmatic APIs (OpenAZ and EzAz)

www.viewds.co
m
XACML Data Flow
31
Context
handler

Policy
decision

point

Policy

administraBon

point

Policy

enforcement

point

ObligaBon

service

Policy

informaBon
point

Subjects

Policy

ObligaBons
Access
request

Request
noBﬁcaBon

Request

A#ribute
queries

Response

A#ributes

Response
context

Environment

Resources

Access
requestor

A#ribute
query
A#ributes

Resource
content

Resource
a#ributes

Environment
a#ributes

Subject
a#ributes

www.viewds.co
m
32
Policy
Allow
Deny
I don’t know
XACML: A machine
that turns attributes
and policies into
decisions
+
ObligaBons
and

Advice

www.viewds.co
m
XACML Flow
33
AuthZ
Request
AuthZ
Response
LDAP
request
LDAP
reposnse
SAML/XML or
REST/JSON

www.viewds.co
m
34
<Request>
<Subject>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">
<AttributeValue>gil@gilkirkpatrick.com</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://
www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>http://
app.example.com/projects/docs/pricelist2014.html</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/
2001/XMLSchema#string"> <AttributeValue>read</AttributeValue>
</Attribute>
</Action>
</Request>

www.viewds.co
m
35
{
"Request" : {
”Subject” : { ”Attribute”: {
”Id” : ”subject-id”,
”Value” : ”gil@gilkirkpatrick.com”
},
},
”Action” : { ”Attribute”: {
”Id” : ”action-id”,
”Value” : ”read”
}
},
”Resource” : {
”Attribute”: {
”Id” : ”resource-id”,
”Value” : ” http://app.example.com/projects/docs/pricelist2014.html”
},
}
}

www.viewds.co
m
XACML Policy Model
§ Policy Set
§  Policy combining algorithm
§  Policies
§ Policy
§  Target
§  Rules
§  Rule combining algorithm
§  Obligations
§  Advice
36
§ Target
§  Resource
§  Subject
§  Operation
§ Rule
§  Condition
§  Effect
§  Allow
§  Deny

www.viewds.co
m
XACML
Pros
§  Externalizes authZ
§  Standardized policy language
§  Well thought out
§  Flexible and extensible
§  XML-based
§  Instantaneous deprovisioning
§  Can work with pretty much any
application
§  Plenty of vendors
§  Incorporates application and user
Cons
§ Over-elaborated for many
scenarios
§ Does not address passwords,
user authentication or consent
§ Every access implies IPC
37

www.viewds.co
m
User-Managed Authorization
39
§ Described as a new
profile of OAuth 2
§ But starts with some
different fundamental
assumptions
§ Not fully baked…

www.viewds.co
m
Different Assumptions Than OAuth2
§ Controls access by people who are not the resource owner
§ Defines access using resource sets and scopes (“nouns and
verbs”)
§ Formalizes the relationship between resource servers and
authorization servers
§ Explicit recognition of responsible parties as part of the “Binding
Obligations” spec
40

www.viewds.co
m
UMA Roles
41
Client
An application making
resource requests on
the requesting
party's behalf
Requesting
Party
The entity that
seeks to access a
resource using a
client
Service that
provides access to
resources through
APIs
Resource
Server
Entity that can make
authorization
decisions about a
resource
Resource
Owner
Authorization
Server (AS)
Service that governs
access to resources
by creating tokens

www.viewds.co
m
UMA Tokens
42
RPT
Requesting Party Token –
token that represents the
authorization status of the
requesting party and client
aka “the user”.
PAT

Protection API Token –
OAuth2 token used to
register resource server and
resource sets
AAT
Authorization API Token –
OAuth2 token used to protect
access to the authorization
API of the authorization
server. It associates the
requesting party, the client,
and the authorization server

www.viewds.co
m
Canonical UMA Flow
43
2
Register
RS
4
Register
resource
set
1
Register
application
4
Authenticate
client
6
Authenticate
7
AAT
12
Request
RPT
10
Register
permission
13
Protected
resource
7
Operate
client
9
Request
resource
11
Grant
perm
ticket
3
PAT

www.viewds.co
m
Responsibility for Authorization Decision
44
AuthorizaBon

Server

Resource

Server

www.viewds.co
m
UMA
Pros
§ Externalizes authZ from
application
§ Fits well with web architecture
§ Accommodates policy-based
authorization
§ Supports user and application
authN and authZ
§ Puts resource owner in control
§ Leverages OAuth2
Cons
§ Not fully baked
§ Appears complex
§ No definition of policy
§ No major adopters… early days
yet
45

www.viewds.co
m
46
Reduces

password

use

Separates

authZ

code

from
app

Resource

owners

deﬁne

policy

Policy

instead
of

code

Mobile,

web,
and

API

friendly

RBAC
ABAC
CBAC
Scalable

and
fast

XACML

OAuth2

UMA
?

www.viewds.co
m
The Chef Recommends
§ Use OAuth2 to externalize web authN and authZ
§ Use XACML as the authorization policy engine behind the
authorization server
§ Keep an eye on UMA – it formalizes a lot of things people are
doing with OAuth2 on an ad hoc basis
47

CIS14: Authorization: It's What's for Dessert

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (6)

Similar a CIS14: Authorization: It's What's for Dessert

Similar a CIS14: Authorization: It's What's for Dessert (20)

Más de CloudIDSummit

Más de CloudIDSummit (20)

Último

Último (20)

CIS14: Authorization: It's What's for Dessert