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

nm

elbo

urne

nsy

dney

nsa

nta

cruz

www.viewds.com

n e w

Cookies and Hash: Basic Identity and Access Management Recipes Authorization

Gil Kirkpatrick [email protected]

Copyright © 2014 ViewDS Identity Solutions www.viewds.com 2

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

Copyright © 2014 ViewDS Identity Solutions www.viewds.com

Ingredient #0

3

No f*cking passwords!


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?


Ingredient #2

5

§ Separate authorization code from the application § Manageability § Auditability § Security § Maintainability § Convenience § Efficiency


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


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


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


Ingredient #5

9

§ Authorization has to be fast and scalable § Mobile friendly § Web friendly § API friendly


Ingredient #6

10

§ Accommodate different authorization models § User consent § Role-based Access Control

(RBAC) § Attribute-based Access Control

(ABAC) § Context-based Access Control

(CBAC)


Authorization Technologies

11

XACML OAuth 2 UMA

OAuth 2


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


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


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


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

Refresh

Refresh token - Used to generate another access token without requiring the resource owner to reauthorize the request


Canonical OAuth2 Flow

AuthZ Request

AuthZ GrantAuthZ GrantAccess Token

(Refresh Token)

Refresh Token

Protected ResourceAccess Token

Protected Resource

Access Token

Access Token

Access Token

Protected Resource

Authenticate


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 AuthZrequest

5 AuthZGrant

4 AuthN/AuthZ

6 AuthZGrant

7 AccessToken

1 Access withno token

2 Accessdenied

10 Protectedresource

8 Access withtoken

9 Validatetoken


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 AuthZrequest

4 AuthN/AuthZ

5 AccessToken


2 Accessdenied

7 Protectedresource

6 Access withtoken

JS


Grant: Client Credentials

3 AuthZrequest

4 AccessToken


2 Accessdenied

6 Protectedresource

5 Access withtoken

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


Grant: Resource Owner Credentials

4 AuthZrequest

3 Username and password

5 AccessToken


2 Accessdenied

7 Protectedresource

6 Access withtoken

Notes: 1.  Resource owner

provides resource credentials to client

2.  Client authenticates with AS and provides RO’s credentials

3.  Refresh tokens are supported


Scopes

22


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


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


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

XACML

~

}


XACML is dead.

Andras Cser, Forrester May 2013 http://blogs.forrester.com/andras_cser/13-05-07-xacml_is_dead

27

~

}


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

~

}


XACML isn’t dead, it just smells funny.

Gil Kirkpatrick, ViewDS 2014 With a tip of the hat to Frank Zappa


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)


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 noBficaBon

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


Policy

Allow Deny

I don’t know

XACML: A machine that turns attributes and policies into decisions

+ ObligaBons and Advice


XACML Flow

33

AuthZ Request

AuthZ Response

LDAP request

LDAP reposnse

SAML/XML or REST/JSON


<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>[email protected]</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>


{ "Request" : { ”Subject” : { ”Attribute”: { ”Id” : ”subject-id”, ”Value” : ”[email protected]” }, }, ”Action” : { ”Attribute”: { ”Id” : ”action-id”, ”Value” : ”read” } }, ”Resource” : { ”Attribute”: { ”Id” : ”resource-id”, ”Value” : ” http://app.example.com/projects/docs/pricelist2014.html” }, } }


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


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

UMA


User-Managed Authorization

39

§ Described as a new profile of OAuth 2 § But starts with some different fundamental assumptions § Not fully baked…


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


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


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


Canonical UMA Flow

43

2 RegisterRS

4 Registerresource set

1 Registerapplication

4 Authenticateclient

6 Authenticate

7 AAT

12 Request RPT

10 Registerpermission

13 Protectedresource

7 Operateclient

9 Requestresource

11 Grant permticket

3 PAT


Responsibility for Authorization Decision

44

AuthorizaBon Server

Resource Server


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


Reduces password use

Separates authZ code from app

Resource owners define policy

Policy instead of code

Mobile, web, and API friendly

RBAC ABAC CBAC Scalable and fast

XACML

OAuth2

UMA ?


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

Q&A

48

Technology

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