Interworking with an External Dynamic Authorization System

Group Name: SEC WGSource: Qualcomm Inc., Wolfgang Granzow & Phil HawkesMeeting Date: SEC#20.2, 2015-12-03Agenda Item: Dynamic Authorization

Background• There are currently five (5) high level dynamic authorization

architectures, all with advantages and disadvantages– 4x client-based proposals (using access tokens)

• Delegation of existing authority – not issuing new authority– 1x server-based proposals (dynamically updating ACPs)

• New conditions for authorizing &/or updating ACPs• Supports Hosting CSE decisions and delegation decisions made by back-end

– Authors’ opinion • Client-based and server-based dyn auth are complementary: suit different

scenarios• Strict deadline for stage 2 details• R01

– minor changes to some slides. – New slides identified using in the top left corner

2

NEW

NOTE• This proposal focusses on a approach where the

Hosting CSE does not make decisions about dynamic authorization- the decisions are made elsewhere – e.g. At an Authorization Server

• This is not the only valid approach – IDCC proposal DAA4/SLDA supports the Hosting CSE

making decisions– Such a system could work in parallel with our proposal, we

are not opposed – In the author’s opinion, the present proposal minimizes

standardization effect, and has most likelihood of making it into Rel 2.

3

NEW

Suggestion• Multiple Aspects to Dynamic Authorization

1. How is a delegation authorized?• Architecture: Entities, Messages, parameters• Protocol level details: Defining Policies

2. What parameters are exchanged over oneM2M msgs?3. How is an delegation used in an access control decision?

• Why don’t we A. Leave (1) completely out of scope.

• Assume that an external Dynamic Authorization System (e.g. OAuth, UMA) provides this functionality.

• Can always define a oneM2M-based Dyn Auth System in more detail (or profile an existing Dyn Auth System) at some time in the future.

B. Focus on (2) and (3).

4

Suggestion (2)• Integrated with existing ACPs– Enhance ACPs to include rules which are compared

against Authorized Delegations.– NOT alternative to ACPs.

• Create a common framework providing Client-based and Server-based dyn auth– Decisions made at an Authorization server

• (Author’s opinion) This approach minimizes impact on – ARC WG work & changes to TS-0001– SEC WG work & changes to TS-0003

5

Ext Dyn Authz System Actors• Subject

– Stakeholder (end-user, business, org) or entity whose authority can be delegated– Could also be dictating access control policy on the Host CSE– Not “Token Subject” of DAA3!

• Authorized Server– Trusted entity issuing data objects (on behalf of Subjects) describing authority

delegated by the Subject. These data objects are called Authorized Delegations (more details in a couple of slides)

• Resource Server Agent– Functionality interacting with the Ext Dyn Authz System of behalf of Hosting CSE

• Resource Server Agent appears to the Ext Dyn Authz System as Resource Server,• Difference to normal Ext Dyn Authz System: Hosting CSE hosts the resources • Hosting CSE trusts the Resource Server Agent

• Client Agent (Token/Client-based dyn auth only)– Functionality interacting with the Ext Dyn Authz System of behalf of Originator

• Client Agent appears to the Ext Dyn Authz System as a Client• Difference to normal Ext Dyn Authz System: Originator requests the resources.• Originator trusts the Client Agent

6

NEW

Out of Scope & In Scope• Interactions between Ext Dyn Authz System actors are out

of scope• We want to standardize– Parameters exchanged between oneM2M system and Ext Dyn

Authz System • Client Agent Originator• Resource Server Agent Hosting CSE

– (Client-Based dyn auth) Hosting CSE and Originator to forward data between Client Agent and Resource Server Agent • Nature of the forwarded data is out of scope

– Data object representing a delegation, processed by Hosting CSE

– How delegation data object is used in access control decisions

7

NEW

Two new Data Objects• Authorized Delegation (AuthzDlgn)

– Outcome of the interaction with the Ext Dyn Authz System– Describes the authorization (in form of subject-managed roles) issued

by an Authorization Server on behalf of a Subject (user, business, organization). • Can optionally identify one or more Originators• AuthzDlgn can include expiry.

• Permitted Delegation Rule (PermDlgnRule)– (Optional) New parameters inside an access control rule.– A set of values (including wild cards) matched against corresponding

parameter values of Authorized Delegation(s) and the request – When evaluating the access control rule for a particular request:

• IF an Authorized Delegation matches a Permitted Delegation Rule, • THEN behave as if Originator’s identifier was in accessControlOriginators.

• Further details on parameters in a few slides

8

Server-based Flow (ACP Update)

9

oneM2M Originator

Resource Server AgentoneM2M Hosting CSE

External Dynamic Authorization System

Details of the Authorization System are not addressed in the present document

oneM2M System

a. Mcc/Mca Request

Authorization Servers

f. Mcc/Mca Response

c. List of PermDlgnRules

d. Authorized Delegation

Authorized entity manages Permitted Delegation Rules in <accessControlPolicies>

e. access control decision = allowed

b. access control decision = denied

Advantage: No impact on Originator

Client-based Flow (Token)

10

oneM2M Originator Client Agent

Resource Server AgentoneM2M Hosting CSE

External Dynamic Authorization System

Details of the Authorization System are not addressed in the present document

oneM2M System

a. Mcc/Mca Request

Client Based Flow Allowed

Authorization Servers

NOTE 1: In some cases, the Originator might not need to provide the access token in subsequent requests. NOTE 2: Final Mcc/Mca response is not shown

e. Mcc/Mca Response /w Client Agent Initialization

f. Client Agent Initialization

g. Authorized Delegation,Access Token

d. Client Agent Initialization

c. List of PermDlgnRules, Client Based Flow Allowed

i. Access Tokenj. Authorized Delegation

Authorized entity manages Permitted Delegation Rules in <accessControlPolicies>

h. Mcc/Mca Request /w Access Token

k. access control decision

b. access control decision = denied

Advantage: Works with OAuth-based Ext Dyn Authz Systems

Implementation and Deployment Options• The Originator and Client Agent could be

i. Integrated to a single component and indistinguishable.ii. Distinct components on a single device.iii. Implemented on distinct Nodes.

• We should try to support options i + ii. – Option iii requires defining messages exchanged between devices.

Won’t get this in Rel 2, maybe in future releases?• We should support scenarios where a single Client Agent acts on

behalf of multiple Originators. For example:– App presents itself as multiple AEs, and App contain a Client Agent

which acts on behalf of all these AEs.– A single Client Agent on a Node could act on behalf of multiple

Originators on the same Node.– A Client Agent on a MN could act on behalf of multiple Originators on

the MNs, ASNs and ADNs registered to that MN.i. Similar comments apply for Hosting CSE and Resource Server Agent

11

Summary of parameters

12

Parameter (JWT elements)

Authorized Delegation

Permitted Delegation Rule

Matching rule

Issuer (iss) AS FQDN [1] FQDN [1..n](wildcards allowed?)

At least one match

Subject (sub) AS-assigned Subject-ID [1]

Subject-ID [0..n] (wildcards allowed?)

At least one match“anonymous” allowed

Audience (aud) CSE-ID regex*[0..n] Not present Hosting CSE-ID matches AuthzDlgn.aud

Authorized Originators (azo**)

AE/CSE-ID [0..n] (including wildcards?)

AE/CSE-ID [0..n](wildcards allowed?)

Orig.’s AE/CSE-ID matches both AuthzDlgn.azo and PermDlgnRule.azo

Dyn Authz Roles (rol**)

Dyn Authz Role-ID [0..n]

Dyn Authz Role-ID[0..n] (wildcards allowed?)

At least one match between AuthzDlgn.rol matches PermDlgnRule.rol

Access Token Usage (atu**)

Client-based only:“auto”, “required”

Not present. See next slide

AuthDlgn ID AS assign AuthDlgn ID AuthDlgn ID [0..n] (wildcards allowed?)

At least one match

* The hosting CSE only checks this regex once (when AuthDlgn is received)** azo, rol and atu would be new elements of JWT (JSON Web Token RFC 7519) .

Access Token Usage parameter• Message size is important.• If can avoid resending access token, while still knowing that the

Hosting CSE will still consider the Authorized Delegation, then that would be great!– Some scenarios require including access token in every request.

• Access Token Usage:– Assigned by Authz Server on behalf of Subject.– “required” means the Authorized Delegation will be considered in a

subsequent requests only if that subsequent request contains either• the access token or • (in the case of a self-contained access token including the Authorized Delegation

– which would be a very large access token) an identifier for the Authorized Delgation.

– “auto” means the Authorized Delegation will be automatically considered in all subsequent requests – where or not the access token (or identifier) is included in the request.

13

Other optional parameters• JWT elements include– nbf: Not Before– exp: Expiry– iat: Issued At

• These elements can be provided in Authorized Delegations

• Permitted Delegation Rules can include similar elements to limit the time window in which it applies

• These are compared against the time that the request is processed.

14