
72e096eb6afa83e0b78ea69f6116ca87.ppt
- Количество слайдов: 14
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc. , Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20. 2, 2015 -12 -03 Agenda Item: Dynamic Authorization
Background • There are currently five (5) high level dynamic authorization architectures, all with advantages and disadvantages – 4 x client-based proposals (using access tokens) • Delegation of existing authority – not issuing new authority – 1 x 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 • R 01 – minor changes to some slides. – New slides identified using NEW 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 DAA 4/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
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 one. M 2 M 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 one. M 2 M-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 Clientbased 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
NEW 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 DAA 3! • 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 one. M 2 M 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
Two new Data Objects • Authorized Delegation (Authz. Dlgn) – 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 • Authz. Dlgn can include expiry. • Permitted Delegation Rule (Perm. Dlgn. Rule) – (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 access. Control. Originators. • Further details on parameters in a few slides 8
Server-based Flow (ACP Update) Advantage: No impact on Originator 9
Client-based Flow (Token) Advantage: Works with OAuth-based Ext Dyn Authz Systems 10
Implementation and Deployment Options • The Originator and Client Agent could be i. iii. Integrated to a single component and indistinguishable. Distinct components on a single device. 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: i. ii. iii. 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. • Similar comments apply for Hosting CSE and Resource Server Agent 11
Parameter Authorized (JWT elements) Delegation Issuer (iss) AS FQDN [1] Permitted Delegation Rule Matching rule 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 Authz. Dlgn. aud Authorized Originators (azo**) AE/CSE-ID [0. . n] (including wildcards? ) (wildcards allowed? ) Summary FQDN [1. . n]allowed? ) At least one match of parameters (wildcards Orig. ’s AE/CSE-ID matches both Authz. Dlgn. azo and Perm. Dlgn. Rule. azo Dyn Authz Roles Dyn Authz (rol**) Role-ID [0. . n] Dyn Authz Role-ID[0. . n] At least one match (wildcards allowed? ) between Authz. Dlgn. rol matches Perm. Dlgn. Rule. rol Access Token Usage (atu**) Client-based only: “auto”, “required” Not present. Auth. Dlgn ID AS assign Auth. Dlgn ID [0. . n] (wildcards allowed? ) See next slide At least one match * The hosting CSE only checks this regex once (when Auth. Dlgn is received) 12 ** 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