Trust Eleva,on Architecture v03

Transcription

1 Trust Eleva,on Architecture v03 DISCUSSION DRAFT Andrew Hughes 1

2 Purpose of this presenta,on To alempt to explain the Trust Eleva,on mechanism as a form of ALribute Based Access Control To aid in understanding the func,ons involved in Trust Eleva,on To show rela,onships, informa,on flows and repositories To set a basis for further specifica,on 2

3 A Bit ABout ABAC ALribute Based Access Control Use NIST SP as reference source Subject tries to get Resource Policy Enforcement Point (PEP) intercepts request Policy Decision Point (PDP) checks supplied alributes versus access control policy Can obtain addi,onal alributes from Environmental Condi,ons, Policy Informa,on Point, others PDP instructs PEP to permit or deny access 3

4 4

5 Why discuss ABAC alongside TE? ABAC is concerned with making access control decisions based on policy, transac,on-,me informa,on and sta,c informa,on Trust Eleva,on is concerned with sa,sfying access control decisions that need addi,onal alributes to sa,sfy policy Trust Eleva,on allows pre- determined step up criteria from one level of assurance to other levels of assurance 5

6 TE As A Mode Of ABAC One way to think about the purpose of Trust Eleva,on is to provide addi,onal informa,on that is required to make access control decisions Trea,ng TE as a mode of ABAC is not the only way to represent it, but the ABAC model offers hooks that seem to fit the TE model well 6

7 7

8 TE PaLerns WriLen as ABAC PaLerns To aid in understanding actors, func,ons and responsibili,es, I have created Trust Eleva,on PaLerns in the form of NIST SP ABAC PaLerns These are NOT sequence diagrams These are NOT protocol structure diagrams NOTE: The first pass at the diagrams are interspersed with explanatory slides. AHer the 3 rd PaLern slide I have duplicated the three palern slides to allow you to flip between them easily 8

9 PaLern 1: Basic ABAC A recrea,on of the ABAC PaLern from SP Should be a familiar construct Shows the well known PDP, PEP, PIP, PAP and policy repository 9

10 10

11 PaLern 2: Basic Trust Eleva,on Adds in a minimal set of addi,onal func,ons as described in the Trust Eleva,on deliverables These elements should be able to handle the simple TE Use Cases The RP from the TE Use Case is now split into the relevant ABAC bits I have renamed the LOA Repository to TE Method Repository 11

12 12

13 Notes on Basic TE PaLern The PIP is an ac,ve agent Able to obtain addi,onal informa,on from the Subject (User, User Agent or Device) Able to compose answers to the PDP s requests for more informa,on needed to make the policy decision TE Method Determiner is shown as an input to the PDP instead of the PIP TE MD is a form of policy engine: takes requested LOA and required LOA, returns TE Method(s) that can be used to step up {is this what is supposed to occur? A single answer or a list of answers? See slides later on about this func,on} The TE Method Repository contains informa,on about the TE Methods and how they step up the LOA The Method Repository is configured in tandem with the TE MD using the TE Admin Point 13

14 PaLern 3: Extended TE Adds addi,onal func,ons and alribute sources Should be able to support all TE Use Cases, including recursive, federated, pre- loaded creden,al assurance and other advanced cases Don t worry too much about the complexity of the boxes and lines this is NOT taking the place of a sequence diagram! 14

15 15

16 Notes on Extended TE PaLern Imagine that there is some form of orchestra,on engine (possibly the PIP itself) ensuring the steps are done in the correct order Imagine that the PEP/PDP are able to do a recursive response/ request with the Subject if needed Imagine that the PIP is able to invoke orchestrated events to obtain needed alributes e.g. seek addi,onal verified alributes from addi,onal alribute provider that might need User authen,ca,on No,ce that the User/Creden,al Provisioning Func,ons provide the TE Method Repository and ALribute Repository with configura,on informa,on This could enable pre- loaded TE Methods and other op,miza,ons 16

17 17

18 18

19 19

20 Compare to TE Core Model Flip through the next series of slides to see where the Core Model boxes apply 20

21 21

22 22

23 23

24 24

25 25

26 Make Sense? By rela,ng the TE Model to ABAC Access Control palern language it should help others to relate and understand the concepts What else is needed? Data Model for TE Method Repository Use Cases Sequence Diagrams Func,onal Descrip,ons Interface Specifica,ons Finite state machine? If the TE Extended PaLern is sufficiently rich, we can begin defining tailored material 26

27 PDP and PIP FUNCTIONAL ENHANCEMENTS 27

28 PDP Enhancements The PDP and PIP must be enhanced to handle TE messages and calls The PDP must be able to Consume Trust Eleva,on Policy Direct the PIP to perform the indicated TE Method Signal to the PEP in a way that the Subject is able to consume 28

29 PIP Enhancements The PDP and PIP must be enhanced to handle TE messages and calls The PIP must be able to Parse instruc,ons about TE Methods from the PDP Orchestrate a series of ac,ons needed to execute each of the TE Methods Discover appropriate informa,on sources for each listed TE Method 29

30 The TE Method Determiner and TE Method Repository ADDITIONAL DETAILS 30

31 Method Determiner Role The TE Method Determiner returns the Method Determined when given Current Method, LOA and one of Requested Method or LOA Returns Null?/False? if no valid Methods match the request {TE Method, LOA} Current == {TE Method, LOA} Requested + {TE Method} Determined MD does a simple table lookup against the TE Method Repository Not a mathema,cal evalua,on Not a?procedural/algorithmic? Process i.e. Star,ng from here, where do I end up, given these constraints 31

32 Method Determiner Basic I/O Input A Input B Input C Output {TE Method} Current {LOA} Current {LOA} Requested {TE Method} Determined (A list of methods) {TE Method, LOA} Current == {TE Method, LOA} Requested + {TE Method} Determined Need to Discuss does the MD need informa,on about which Factor was used, or which Threats are being mi,gated? 32

33 Method Determiner Simple Table Structure Star7ng TE Method Star7ng LOA Target LOA Step Up TE Method HMMM need to talk about this more Is this table rich enough to make expressing the step up methods simple? Or will the Admin be forced to list a very complex set of poten,al combina,ons? 33

34 The Method Determiner Func,ons Func,ons Confirm TE Method & Current TE LOA validity Does the TE Method match the TE LOA? Can the MD be asked to list all informa,on in the Repository tables? Determine TE Methods Returns list of TE Methods that could be used to go from Current TE Method + Current TE LOA- > Requested LOA Inputs Current TE Method Current TE LOA Requested TE LOA (op,onal) Requested TE Method (op,onal) Cycle counter (op,onal) Indicator for how many,mes this Subject has been around the loop for this AuthZ alempt Op,ons (Op,onal) e.g. subject preferences, RP preferences, other constraints, transac,on audit tags Outputs List of TE Methods that could be used to go from Current TE Method + Current TE LOA - > Requested LOA Could return Null/False if no TE Methods apply TE Hints to the PDP & PIP (op,onal) Enabler for local implementa,on details (e.g. which AuthN provider, Subject constraints, transac,on audit tags, etc.) Controls Policy restric,ons that forbid certain combina,ons or situa,ons from returning an answer Some kind of controls around audit & logging 34

35 Method Repository Data Model Need to discuss! 35

36 TE Message Structure(s) Data structure of TE Messages TE Method Determiner <- > TE Method Repository TE Method Determiner <- > PDP TE Extensions needed for PDP <- > PIP SAML Message Example JSON Message Example OIDC Message Example Other Examples? 36

37 PaLerns for Use Cases Need to discuss Diagrams/sequences for the range of Use Cases The major differences should be in the orchestra,on that the PIP does Dynamic versus Sta,c (preloaded values) step up Recursive step up queries (where does the recursion 37