AWS re:Invent 2022 - [NEW] Use policies to manage permissions w/Amazon Verified Permissions (SEC335)

AWS re:Invent 2022 - [NEW] Use policies to manage permissions w/Amazon Verified Permissions (SEC335)

AWS re:Invent 2022 - [NEW] Use policies to manage permissions w/Amazon Verified Permissions (SEC335)

Permissions in your application can be based on several factors, including principal’s roles and attributes, resource data, and other contextual information such as method of authentication. By using policy-based permissions, you can decouple authorization logic from your applications, gain better visibility and auditability into access rules, and manage permissions at scale. Join us in this session to learn how policy-based permissions can be applied to your applications using Amazon Verified Permissions, and discover how this fits into the end-to-end journey of application authentication, authorization, and fine-grained access control.

Learn more about AWS re:Invent at https://go.aws/3ikK4dD.

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInvent2022 #AWSreInvent2022 #AWSEvents


Content

0.36 -> - Hi, good afternoon everybody.
2.01 -> Thank you very much for coming.
3.87 -> Appreciate there are a lot of good sessions out there.
6.09 -> So thank you for making this one part of your day.
10.26 -> The topic is a new service
13.47 -> that we launched on Monday
15.9 -> in gated preview called Amazon Verified Permissions.
19.5 -> And specifically how you use Amazon Verified Permissions
22.98 -> to manage permissions within your application.
26.07 -> My name's Julian Lovelock.
27.39 -> I'm the product manager.
29.22 -> And I'll be joined on stage
30.75 -> by my colleagues, Emina and Mahmoud.
32.97 -> And I'll let them introduce themselves
34.98 -> as they take the stage.
37.59 -> So how's the day or this particular session breakdown?
41.52 -> I'm gonna do an introduction to the product explaining
45.42 -> why we built it and a little bit about high level.
49.2 -> What it does.
50.61 -> Mahmoud's gonna get into more depth,
52.98 -> talking about how you would integrate your application
55.86 -> into this service.
57.99 -> And then Emina will be talking
59.79 -> about the Cedar policy language
62.13 -> which is the language in which the policies
64.44 -> for this permission system are written.
69.54 -> Like any good solution, it starts with a problem.
73.29 -> So what is the problem that we were trying to solve?
79.35 -> In a word that problem is permissions.
82.95 -> Or more broadly.
84.57 -> How does an application developer manage the permissions
88.23 -> within their application and authorize user actions
92.01 -> based on those permissions?
94.8 -> So whatever application you're trying to build
97.83 -> you have to have some element of permissions management
100.35 -> within that application.
102.33 -> If you're building an online banking application,
105.3 -> you have to think about how do I determine which accounts,
108.78 -> different users are allowed to access
110.49 -> and what transactions they're allowed
111.75 -> to take on those accounts.
113.85 -> If I'm building a photo sharing application
116.34 -> I have to think about who's allowed access to which photos,
119.01 -> who can comment on them, who can create albums, et cetera.
122.7 -> I'm building an HR system.
123.99 -> I have to think about who has access
126.06 -> to different employee records.
127.56 -> Who can access reviews.
128.73 -> Who can submit reviews.
129.75 -> Who can access payroll data.
132 -> It goes on.
132.833 -> So any application that you're building, pretty much,
135.69 -> you need to think about how you manage the permissions
138.03 -> within that application.
139.74 -> And how you authorize user actions within it.
143.91 -> So we can define permissions broadly
147.18 -> as the set of rules that describe what each user
150.75 -> in the application is permitted to do.
154.626 -> And we can express those permissions as policies.
159 -> In the simplest sense, there are two types of policies.
162.78 -> Those that commit you to do something
165.66 -> and those that forbid your user from doing something.
170.76 -> We also see in general terms two authorization models.
176.16 -> There is what we often refer to as RBAC
178.44 -> or role-based access control
181.2 -> which works well in a hierarchical organization.
185.04 -> Where users are divided into a group, into a hierarchy,
188.79 -> and we can assign roles to different groups.
191.37 -> And those roles determine what users
193.35 -> in those groups are permitted to do.
194.82 -> And that, as you might imagine, works well
196.92 -> in a workforce environment
198.84 -> where employees are typically organized
200.79 -> into some sort of a hierarchy.
203.58 -> The challenge that we often see with RBAC based models
206.82 -> is as you make those permissions more granular
211.41 -> you get more and more roles.
214.14 -> And we have customers who've explained to us
215.79 -> that they actually have more roles than employees.
220.23 -> The other model is ABAC, attribute based access control.
224.73 -> This works pretty well in a consumer facing application,
228.57 -> whereas you might imagine your users
230.73 -> aren't divided into nice hierarchies.
234 -> And so you are defining the rules
236.1 -> in an ABAC based model
238.26 -> based on attributes of the resource that you're protecting
242.37 -> or the identity that you are enabling access to.
246.42 -> Or for I should say.
248.16 -> Challenge with ABAC models
250.05 -> is that they can become quite opaque.
253.23 -> Difficult to analyze 'cause these rules
255.45 -> can come out across as quite ad hoc.
261.84 -> So we've established that permissions management
265.41 -> is a must have.
267.63 -> We can logically ask ourselves, "Well how's it done today"?
271.5 -> So through the course of this session
274.14 -> you'll see various different examples thrown at you.
277.35 -> My slides are gonna throw an example at you
279.09 -> that's oriented around a financial services application.
282.51 -> And they gotta protect access
283.98 -> to creating payees and actions like that.
287.7 -> So we imagine a user
289.68 -> of this online banking application needing
292.26 -> to create a payee.
293.88 -> And the application has to figure out
295.92 -> whether said user is permitted to do this.
299.43 -> And what we're gonna see more often than not
302.37 -> is that logic actually embedded
304.86 -> into the code of the application.
308.1 -> You can see there my attempted code.
309.72 -> You can see why I became a product manager
311.55 -> rather than a developer but you get the sense
314.07 -> which is that this code
315.93 -> is gonna have convoluted logic written into it
318.42 -> that protects this particular transaction.
320.13 -> But it's gonna be part of the code.
321.3 -> So what's the issue with that?
324.93 -> Well the issue is that
326.31 -> in order to understand
328.98 -> what or who is allowed to do what in this application
332.13 -> you effectively have to be able to read the code.
335.85 -> Also, every time you change the rules around
338.76 -> who is allowed to do what.
340.29 -> Maybe there's a change organizationally.
342.6 -> Maybe there's a new set of regulations.
344.88 -> Maybe there's an event that requires you
347.01 -> to re-look at the permissions rules within your system.
350.25 -> These things all require you to go back
352.14 -> and change the code of your application.
355.83 -> Which, to put it frankly, is suboptimal.
359.4 -> And then the other thing is audits are difficult.
362.28 -> It's not an unreasonable question
364.71 -> for an auditor to ask, "Okay, who can create payees"?
369.42 -> And if answering that request requires the respondents
373.5 -> to go look at the code
375.15 -> it's gonna be a very lengthy and tedious audit.
381.84 -> So we can begin to understand
384.15 -> some of the characteristics
385.89 -> that we want a modular permission system to have.
390.96 -> We want those permissions to be expressed
393.81 -> as relatively simple, easy to read policies.
399.21 -> We wanna be able to support role based access control
403.02 -> and attribute based access control.
406.68 -> And we want those policies to be auditable
409.38 -> and easy to understand.
411.81 -> If we look at it
412.643 -> from a non-functional requirement perspective
416.58 -> we want very low latency because we're gonna adhere
419.16 -> to zero trust policy strategy.
422.13 -> We're gonna have our application check permissions
424.89 -> for each and every time anyone within
426.57 -> that application does anything.
428.46 -> So that better happen quickly.
430.89 -> It's gotta be highly available
432.06 -> because if the system stops working
434.22 -> then the users can't do anything in the system.
437.691 -> And we want it to be easy to plug in
439.17 -> because if a developer can't plug
440.52 -> this service into their application
443.7 -> they're obviously not gonna use it.
448.08 -> So we've established we need
449.73 -> a permissions management system.
452.31 -> We know the kind of characteristics it has to have.
455.94 -> Why can't we as a development team just build it ourself
458.52 -> as part of our application development?
459.99 -> Why do we need to go to a third party
462.45 -> and take a service from them to do this thing?
466.26 -> Well firstly, it's pretty time consuming to build.
469.68 -> It gets complicated quickly as you start
471.9 -> to try and accommodate many different types of policies.
476.1 -> And it's difficult to do right.
479.22 -> There's some fairly complex mathematics
481.83 -> that sit behind requirements like being able
484.86 -> to analyze policies to understand who can do what
488.28 -> or if one policy contradicts another policy.
491.07 -> If you want to be able to do that
492.27 -> through some automated analysis tools
494.4 -> based on automated reasoning.
497.13 -> And Emina will talk a little bit more
498.63 -> about that in her session.
500.67 -> Or her section I should say.
503.13 -> It may not scale.
504.54 -> What you built to work well with 50 roles
508.59 -> may begin to struggle from a performance perspective
511.77 -> when you have 50,000 roles.
514.83 -> And more often than not governance takes a backseat.
520.41 -> The logic of a permissions management system
523.8 -> that enables you to go and see
525.9 -> who actually created this policy,
527.61 -> when did they create this policy,
529.02 -> how come they were allowed to create this policy,
531 -> does the policy changed?
532.83 -> All of that governance layer is typically left out
535.68 -> in a self-build.
539.67 -> So this is where we'd like
541.83 -> to introduce Amazon Verified Permissions.
544.71 -> As an off the shelf permissions management
547.53 -> and authorization system that meets these challenges.
552.45 -> Essentially what the system does
554.73 -> is to store permissions expressed as policies
558.84 -> and provide a means for your application
561.78 -> to manage these permissions
563.97 -> and to authorize the users of that application against
567.15 -> these permissions by evaluating those policies.
573.3 -> I'm gonna run through some high level use cases
576.09 -> and then I'm gonna hand over to Mahmoud.
577.8 -> And he's gonna get into a bit more depth around
579.6 -> these use cases.
581.13 -> So we're gonna imagine our financial services application.
584.94 -> And we're gonna want to start to think about, okay,
587.16 -> as an application developer.
588.81 -> How do I create and maintain policies in that application?
593.43 -> How does a user of that application create permissions
596.7 -> on the fly?
597.57 -> Let's look at a use case for that.
599.88 -> How does the authorization process work?
602.76 -> And how do we go about auditing?
604.62 -> I'm gonna touch on these at a high level
606.18 -> and then as I said, Mahmoud's gonna get into them
607.8 -> in a bit more detail.
611.94 -> So let's imagine our application developer.
615.03 -> They're creating a financial services application.
618.24 -> There may be a baseline policy
620.37 -> that applies across all users of this application.
623.79 -> Such as allow the account owner not only to have access
628.77 -> to the account and operate on the account,
631.05 -> but also to delegate authority to a second user
635.94 -> in the event that the account owner is not available.
638.58 -> So this would be what we might think of
640.53 -> as a baseline policy.
641.7 -> It's created by the application developer
644.61 -> as part, almost, as an extension
646.14 -> of the code of the application
648.39 -> at the outset and this policy is deployed
650.91 -> along with the application.
656.46 -> And you can see or maybe you can't see
659.28 -> but there's an example here of such a policy.
662.91 -> And as I said, Emina's gonna get more
665.43 -> into the structure of the policy language
667.29 -> but it's basically broken down
668.85 -> into what we describe as a scope.
671.19 -> Which essentially caters to the role-based access control
676.35 -> by defining a set of actions
678.48 -> that a group or an individual user
680.31 -> can take on a set of resources.
683.61 -> And then there's a set of conditions underneath
685.95 -> which accommodates the attribute based access control aspect
690.57 -> which puts qualifiers on those.
695.34 -> Now imagine our end user Jane, our CFO.
699.51 -> She's taken a well earned vacation.
701.52 -> So she needs to delegate access while she's away
705.09 -> to be able to manage this account.
708.03 -> So this is an example where an action by Jane
711.63 -> within the application is gonna result
713.58 -> in a policy being created in the underlying policy store.
717.48 -> In this case a policy that gives permission
720.75 -> to Jeff to manage the account specific resource
725.01 -> during the period of Jane's vacation.
728.67 -> So that when our application end user Jeff logs
731.49 -> onto the application and, for example, tries
733.56 -> to create a payee on the account.
737.46 -> The application calls verified permissions
740.07 -> and says, "I've got this user Jeff.
742.8 -> He's trying to take this action create payee
745.14 -> on this account, five one five...
746.91 -> Can't remember what account.
747.743 -> Use five five three dot dot dot.
749.67 -> Is this permitted or not"?
751.83 -> And the permissions management system is gonna come back
754.59 -> with an allow or deny based on
756.39 -> an evaluation of the policies.
757.77 -> And this is all gonna happen in a matter of milliseconds.
760.68 -> Jeff is gonna be blissfully unaware
762.93 -> that his permissions have been checked
764.58 -> and assuming he's allowed to do it
766.44 -> he's gonna carry on and create that payee.
772.05 -> And then our final persona in this story is our auditor
776.43 -> who wants to have that view across all of the different...
780.99 -> It's like the auditor's the most popular one
782.43 -> to take photos of.
783.263 -> I wonder why that is.
784.17 -> Who basically wants to have that view
788.16 -> across all of the permissions that have been created.
791.97 -> Who's basically benefited from using these permissions?
796.23 -> And he's gonna be able to do that
798.81 -> based on a set of analysis tools
800.94 -> that we provide as part of the product
803.43 -> as well as services like CloudTrail
807.03 -> to which audit logs are gonna be written.
808.71 -> And he's gonna be able to use the normal CloudTrail tools
811.86 -> to view those audit logs and see what happened.
816.36 -> So at this point I'm gonna hand you over
818.19 -> to my colleague Mahmoud.
819.69 -> And he's going to be walking through
821.07 -> in a little bit more depth a sample application for you.
826.95 -> - Thank you Julian.
828.96 -> Hi everyone, good afternoon once again
830.28 -> and thanks for being here.
831.75 -> My name is Mahmoud Matouk.
832.833 -> I am a solutions architect with AWS Identity.
835.59 -> And in this section of the session
837.15 -> we'll be looking at how to get started
839.1 -> with Amazon Verified Permissions
840.48 -> and what it looks like to build an application
842.43 -> that integrates with this service.
844.47 -> I will first go through a quick walkthrough
847.41 -> into the console and the first few steps to get started.
850.41 -> And then we will look at a demo application
852.09 -> and few authorization scenarios
853.68 -> and how to integrate with this from your code.
857.73 -> So first to get started from the console.
859.44 -> The first thing that comes out is you'll be greeted
862.05 -> with this screen and asked to create a policy store.
865.23 -> You can think about a policy store
866.73 -> as a container of your policy.
868.26 -> So if you have multiple projects, multiple workloads,
871.14 -> probably with different authorization requirements,
873.45 -> then you will be creating multiple policy stores.
877.05 -> The policy store is a container but it's empty.
879.09 -> So you start filling this policy store with policies.
881.67 -> And you can do this simply from the console
883.35 -> by providing a policy description
885.18 -> and then the policy body itself.
887.34 -> We'll go into more details into the policy language
889.74 -> with Emina.
890.76 -> For now this is a simple policy
892.35 -> that allows a principle to access a resource
894.69 -> as long as this principle is the owner of the resource.
899.22 -> You keep adding policies
900.39 -> and build your authorization model with multiple policies.
903.21 -> You can do this using the console.
905.13 -> You can do this using CLI, using APIs.
907.18 -> So it could be also dynamic policies you create
909.42 -> in your application in response to certain actions
911.61 -> like sharing a photo or delegating to another employee
915.36 -> or something like this.
917.52 -> Once you fill your policy store or you create your policies
920.28 -> you can test the behavior of this policy store
922.38 -> with some authorization queries.
924.06 -> You can do this with a simulator
925.44 -> that is built into the console.
926.76 -> This helps you to troubleshoot
928.08 -> how the authorization engine behaves,
931.41 -> troubleshoot your data set, and so on.
933.99 -> To do this you provide these pieces of information.
936.84 -> And this is also the same data that you provide
939.24 -> to a query at run time from the code.
941.4 -> So you provide who's the principal,
942.96 -> what is the action, what is the resource.
945.18 -> And then optionally you can provide request context
948.45 -> which is a free form map.
950.37 -> Things like runtime information,
952.02 -> maybe the IP address of the source,
953.7 -> the current time of the system,
954.99 -> anything that is relevant to the policies
956.76 -> in your policy store.
961.41 -> The last piece of information is providing your dataset.
964.44 -> The dataset is a JSON format that tells the engine
967.59 -> what are my entities
969.18 -> and what are the relationships between these entities.
971.73 -> For example, if I ask the engine,
973.387 -> "Is Bob authorized to view the image?
975.66 -> Image dot jpeg"?
977.07 -> I have to tell the engine who's Bob,
978.99 -> what is an image,
980.19 -> what are the attributes of these entities,
982.2 -> and how they are related to each others.
984.09 -> So the engine resonates over this data
986.7 -> using the policies in my policy store
988.44 -> and tells me if it's allowed or denied.
991.38 -> The simulator tells you the decision.
993.15 -> This is an allow.
994.05 -> And if it's an allow
995.25 -> what was the satisfied policy.
997.44 -> And if it's a deny,
999 -> because, yes, there is no satisfied policy.
1000.51 -> It'll be a plain deny.
1002.24 -> If it's a deny because of errors in your data,
1005.21 -> like missing attributes,
1006.32 -> you're trying to compare certain attributes
1009.26 -> that are not provided as part of your entities.
1011.48 -> It'll also tell you these errors.
1013.01 -> So you can either
1015.23 -> think that this is expected, this is how I designed it,
1017.63 -> or if this is not expected
1019.04 -> then you go back and fix your data sets
1020.75 -> or change your policies as needed.
1023.6 -> This is all part of the development
1024.98 -> of your authorization model.
1028.22 -> This is what you do from the console to get started.
1030.86 -> As I mentioned, same thing can be done
1032.45 -> from the APIs and the CLI.
1034.16 -> So this can be binned into your CI/CD.
1036.44 -> It could be dynamic actions in your application as needed.
1039.74 -> So once I build my policy store,
1042.86 -> how do I use this at run time
1044.78 -> to make authorization decisions in my app?
1047.3 -> We will look at this next
1048.5 -> and for this we will take Onyx to the vet clinic.
1051.98 -> I'm going to use a sample application
1053.36 -> that simulates the vet clinic portal.
1056.21 -> Onyx was always known for eating things he's not supposed
1058.94 -> to be eating and he just got sick.
1060.71 -> So we need to take him to the vet.
1062.84 -> What is the scenario we are looking for?
1065.03 -> Dave is Onyx owner
1066.89 -> and he needs to take them to the vet.
1069.26 -> So he contacted Sally, the office administrator of this vet,
1072.23 -> to scheduled him for an appointment.
1074.63 -> Sally brought him up for an appointment
1076.31 -> with their primary doctor, Dr. Jane.
1078.86 -> Because Dr. Jane is the primary doctor for Onyx,
1081.44 -> she has access to his history
1082.85 -> and the records of his previous visits.
1085.73 -> But she found that Onyx needs an X-ray.
1088.49 -> So she will refer them to a specialist, Dr. Adam,
1091.7 -> who will run the X-ray.
1093.08 -> And with this referral, Dr. Adam gains more access
1095.63 -> into Dave as a client and Onyx as a patient.
1099.71 -> They use this patient portal application
1101.45 -> and we will be looking at few of these use cases
1103.52 -> and how this translates into policies
1105.2 -> and how do I evaluate these policies at run time.
1108.68 -> The first use case is fairly simple
1110.9 -> so viewing client data and scheduling an appointment.
1115.22 -> As we saw there are different personas in this system
1117.59 -> and every persona has different permissions.
1120.47 -> Let's first take a look at the demo of the scenario
1123.41 -> and then we can go back to the drawing board
1125.06 -> and look at our policies and how we structured them.
1128.03 -> Dave is the client.
1129.56 -> If he's signed into the patient portal
1131.39 -> or to the clinic portal,
1132.92 -> he can see his record and information.
1135.17 -> He's allowed to view his profile.
1136.85 -> So if he attempts to do this
1138.23 -> this is an allowed action.
1139.4 -> No issues.
1140.3 -> But he cannot schedule an appointment for himself.
1142.55 -> If he does this it will be denied.
1144.71 -> And if he tries to refer himself to a specialist,
1147.35 -> this will also be denied.
1148.79 -> It is his.
1151.01 -> It is not his job.
1151.843 -> He has to go through the office administrator.
1153.65 -> So we saw three actions.
1155.15 -> Viewing information, scheduling appointment,
1158.63 -> and referring a patient.
1159.89 -> One was allowed.
1161.03 -> Two were denied.
1162.8 -> The next one is Sally accessing the portal.
1166.04 -> She's the office administrator.
1167.48 -> So she sees a more expanded view
1169.46 -> of all clients in this clinic.
1172.31 -> She's allowed to view profiles of these clients
1175.88 -> and she's also allowed to schedule appointment
1178.22 -> but she cannot do referrals.
1179.6 -> So we see that the referral action is denied for Sally.
1182.57 -> But if she goes back
1183.59 -> and attempts to schedule appointment for Dave
1186.23 -> she should be able to do that.
1191.732 -> So how this translates into permissions.
1195.05 -> We have permissions rules
1196.43 -> and we want to translate these permissions into policies.
1199.25 -> The first rule says
1200.27 -> I want to deny all, deny all actions across clinics.
1204.65 -> So let's say this clinic portal is used by multiple clinics.
1207.47 -> I want to make sure that no cross clinic access
1209.99 -> is ever allowed.
1210.823 -> And I can do this with a forbid statement
1212.99 -> that says forbid everything
1215.48 -> when the principal dot clinic ID doesn't match the clinic ID
1218.66 -> of the resource.
1220.19 -> This is a safe check in my system
1222.41 -> that this will never happen.
1224.63 -> The second rule says allow clients
1226.49 -> to view their own records.
1228.14 -> And this can be made as a policy
1230.69 -> that allows a principal who's a type client
1233.93 -> to take an action.
1235.31 -> Client get on a resource that is also a client
1238.25 -> as long as the principal matches the resource.
1240.89 -> We will learn later that there are different ways
1242.72 -> to write the policies and there might be things
1244.88 -> that are more optimized than others.
1246.26 -> So this is just just an example
1247.79 -> of a possible way to map this rule.
1251.12 -> Keep in mind I keep adding these rules
1253.1 -> to my policy store as we saw either from the console,
1255.92 -> from CLI, or whatever.
1258.32 -> The next permission rule says allow administrators
1261.35 -> to view client records and schedule appointments.
1264.47 -> And this can be mapped using a policy,
1266.48 -> a pure rule-based access control policy,
1268.94 -> that says allow office admins to take actions
1272 -> like client get an appointment post on all clients.
1275.27 -> This is purely rule-based access control
1277.07 -> because the permissions are given based on the rule
1279.89 -> of the principle.
1282.23 -> And the next one is allowing primary doctors
1284.87 -> to view records of their clients
1287.24 -> and refer them to specialists.
1289.1 -> This is a mix of a rule-based access control
1291.2 -> and attribute based access control.
1293 -> It's a rule-based access control
1294.44 -> because it applies only to principles who are doctors.
1297.5 -> And it's attribute based access control because
1299.78 -> it's still it has a condition
1301.04 -> that has to match attribute between the principle
1303.8 -> and the client or the resource.
1306.86 -> So I keep adding these policies to my policies tool.
1309.47 -> Let's look at another use case
1311.6 -> and then we will go back to
1313.16 -> how do I do authorization decisions at run time
1316.67 -> and what my application architecture looks like.
1319.186 -> In this use case, Dr. Jane is going to refer Onyx
1324.62 -> to a specialist.
1326.09 -> So let's take a look at the demo first
1328.31 -> and then we go back to the permissions.
1330.14 -> First, if I log in as Dr. Adam who is a specialist.
1333.23 -> At this time, Dr. Adam has no relationship
1335.3 -> with Dave whatsoever.
1336.2 -> So he cannot view the client information.
1338.66 -> He cannot, of course, schedule appointment
1340.49 -> because he's not an office admin.
1342.11 -> And he cannot refer them.
1343.25 -> So all of the actions are denied for Dr. Adam at this time.
1348.05 -> If I log out and try to log as Dr. Jane
1351.05 -> who is the primary provider for Onyx.
1354.74 -> Dr. Jane because it's the primary provider
1356.81 -> should be able to view the record of their patient.
1360.32 -> This is an allowed action
1361.88 -> and should be able to refer them to a specialist.
1364.52 -> So she will submit a referral to Dr. Adam,
1367.22 -> and ask for an X-ray, and set the time bound
1369.77 -> for this referral to three months.
1373.43 -> Now this creates a dynamic policy in the policy store
1377.21 -> that allows Dr. Adam to access the records of Dave and Onyx.
1380.03 -> So if Dr. Adam signs back in to the portal
1383.36 -> he will be now able to view the record of Dave and Onyx.
1388.52 -> So what happened behind the scene?
1390.74 -> We have a rule that says allow specialists
1392.9 -> to view client records during referral period only.
1395.96 -> So this is a time bound and it's dynamic.
1399.05 -> We can do this with a dynamic policy
1400.88 -> that my application creates in the policy store
1402.86 -> that says permit principle that is also a specialist
1406.22 -> to take an action client get on all clients.
1409.61 -> When.
1410.443 -> And then you become very specific with the policies.
1412.28 -> This applies to a specific principal who's Dr. Adam.
1415.19 -> A specific resource who is client, Dave.
1417.38 -> And only within this timestamp.
1419.48 -> Only as long as the query time is before this timestamp.
1423.23 -> You can use the same scenario
1425.24 -> for many use cases like delegation, elevated access,
1428.42 -> sharing data between resources, and so on.
1432.04 -> So what does the application blueprint looks like?
1435.41 -> So we saw six policies.
1437.87 -> I added these six policies to my policies store.
1440.45 -> How does this web application make authorization decision
1443.27 -> at run time?
1444.103 -> We look at one better
1444.936 -> but there are many others.
1446.63 -> For this I have my client application on the left hand side.
1450.26 -> This is the web application.
1451.46 -> Could be a mobile application.
1452.93 -> I have my backend APIs on the right hand side.
1455.36 -> These are the backend of the web portal.
1459.29 -> And then I have API gateway in the middle
1461.57 -> as the access point to these APIs.
1463.76 -> I have Amazon Cognito at the top
1465.65 -> which acts as the identity provider in this case.
1468.26 -> As we saw in the demo, everything starts
1469.91 -> with a user signing in.
1470.99 -> I have to know what is this user entitlements.
1473.6 -> What are their profile attributes and so on.
1476.18 -> And then I have Amazon Verified Permissions at the bottom
1478.46 -> and this is acting as the authorization engine.
1482.12 -> The flow starts by user coming into the application
1484.67 -> and signing in with Amazon Cognito.
1487.1 -> You can optionally federate.
1488.51 -> So it's common scenario that I want my public clients
1491.33 -> to have a username and password
1492.56 -> but I want my employees to sign in
1494.3 -> with their enterprise credentials.
1496.4 -> So you can do that.
1497.6 -> After signing in Cognito issues tokens to the application.
1501.26 -> These tokens are signed, it's tamper proof,
1503.6 -> it has the entitlements and group membership
1505.76 -> and data about the user,
1507.35 -> and you can also inject some runtime information
1509.63 -> like what is insurance status of this client
1513.32 -> and any additional information that is relevant
1515.72 -> to your authorization decisions.
1518.66 -> Every API call that is made then
1520.4 -> from the application carries this token for authorization.
1523.28 -> Simply adding it to the authorization header
1525.29 -> and send it to API gateway.
1527.75 -> API gateway uses Lambda Authorizer to evaluate the decision.
1531.26 -> Lambda Authorizer does four things.
1533.12 -> Verifying the token, formatting a query
1535.88 -> to the authorization service,
1537.65 -> running the query and getting a decision,
1539.9 -> and enforcing this decision by returning
1541.79 -> an allow or denied to API gateway.
1544.16 -> Once the decision returns to API gateway,
1546.71 -> if it's an allow API gateway,
1548.36 -> just forwards the call to the back end.
1550.07 -> If it's a deny and returning unauthorized error
1552.29 -> to the client.
1553.64 -> This is one sample architecture.
1555.05 -> It's serverless architecture.
1556.25 -> Of course you can remove API gateway in both AppSync.
1559.13 -> You can remove this layer on both your custom APIs
1561.59 -> and containers and you can run the same authorization logic
1564.53 -> in your application if you want to.
1567.05 -> So now let's take a closer look at my Lambda Authorizer
1570.11 -> because this is where the integration
1571.52 -> with Amazon Verified Permissions happen.
1574.61 -> In my Lambda Authorizer I want to answer the question
1576.86 -> of whether the principal that is trying to make the call
1579.23 -> is authorized to make this action.
1580.94 -> To put this in a more technical way
1584.06 -> I want to run a query that says,
1585.507 -> "Is Dr. Jane allowed to take the action referral post
1588.858 -> on the resource client, Dave,
1591.08 -> under these runtime conditions"?
1594.29 -> To do this, and this is assembled by form code.
1597.2 -> I have four steps here.
1598.85 -> The first step is retrieving the token
1601.1 -> from the authorization header and just verifying it.
1603.56 -> This is a standard JWT token verification
1606.62 -> using the public key of the issuer.
1609.05 -> The second part is formatting a query
1611.42 -> to Amazon Verified Permissions.
1613.82 -> In this query I have six important information.
1617.12 -> The first one is the policy store.
1619.46 -> What is the policy store
1620.54 -> that you are running this authorization query against?
1622.67 -> As I mentioned, you can create multiple.
1624.53 -> At this time, I will get preview.
1626.09 -> You can create only one
1627.26 -> but long term you'll be able
1629.09 -> to create multiple policy stores.
1630.56 -> So which policy story you are running this query against.
1633.35 -> And then the second piece of information is
1635.06 -> who is your principle.
1636.26 -> And this is information that is driven from the token.
1639.17 -> The second.
1640.003 -> The next one is what is the action.
1641.63 -> And the action can be coming from the API context.
1643.88 -> What is the resource path you are trying to access
1646.13 -> and what is the action?
1646.963 -> Is it a post, is it the gate, is it a bot?
1648.89 -> And so on.
1650 -> And as I mentioned, this is one pattern.
1651.38 -> You can think about unlimited patterns
1653.81 -> that you can have mapping in your application and so on.
1657.796 -> And number four is the resource.
1660.44 -> The resource could be identified
1662.03 -> as a resource path parameter, a query string, a header
1667.46 -> that is in the API call.
1668.6 -> So you can drive all of this information
1670.19 -> from the API context and build it in your query.
1673.13 -> And then the next one is optional context.
1676.1 -> As I mentioned, this is a free form map.
1678.02 -> So in this case I'm providing what is the query time.
1680.18 -> What is the current time of my system.
1682.49 -> And then the last one is the data set which is
1686.3 -> which tells the engine who is Dave.
1687.98 -> Who is Jane.
1689.03 -> What are their relationships.
1690.23 -> What are their attributes and so on.
1693.35 -> The next step is to run the authorization query
1695.81 -> with a service.
1696.643 -> And this is as simple as making
1697.94 -> an end authorized call against the service client.
1701.15 -> Amazon Verified Permissions is just a service
1703.46 -> like the rest of AWS services.
1704.75 -> So you create a client using the SDK
1706.52 -> and then you run APIs against this client in instance.
1710.3 -> Number four.
1711.14 -> You got a a decision from Amazon Verified Permissions
1714.05 -> and now you are trying to analyze the permissions
1716.39 -> and see what was the decision.
1717.56 -> Is it an allow or deny?
1719.15 -> And then number five would be enforcing this
1722 -> by returning a policy from the Lambda Authorizer
1723.967 -> that says allow this call or deny this call.
1727.703 -> This is fairly simple and we can take a few takeaways
1730.7 -> from the code.
1731.66 -> Now this is your authorization logic.
1734.96 -> This is your logic in the code.
1736.42 -> It doesn't matter whether you have three actions
1738.92 -> or 300 actions.
1740.12 -> It doesn't matter if you have 10 user types
1742.25 -> or a hundred user types.
1743.84 -> This code doesn't change much.
1746.24 -> Like the code can stay the same
1747.83 -> and all of the authorization decisions
1749.87 -> is offloaded to Amazon Verified Permissions.
1754.009 -> The other point, that by offloading this
1755.93 -> to a managed service.
1756.83 -> You don't have to worry about the operational heavy lifting
1760.37 -> and the scale and the high availability
1762.11 -> of the service behind the scene.
1763.46 -> You just make authorization decisions
1765.2 -> and enforces them at run time.
1767.96 -> With this I'm going to hand it over to Emina
1770.24 -> to talk more in depth about the Cedar policy language
1772.873 -> and the authorization engine behind the scene.
1776.537 -> - Thank you.
1779.87 -> Hello everyone.
1780.83 -> My name is Emina.
1782.15 -> I'm a senior principal applied scientist at AWS.
1785.42 -> And I'm a member of the team who designs
1787.79 -> and builds the Cedar language.
1790.28 -> This part of the talk is going to be a deep dive,
1792.71 -> a technical deep dive,
1793.82 -> into our design and development process.
1795.92 -> And we're gonna talk about what makes Cedar unique
1798.77 -> in the space of authorization languages
1800.87 -> that you're going to find today.
1803.06 -> So Cedar is a new domain-specific language
1807.11 -> designed specifically for authorization
1809.45 -> and it comes with batteries included.
1811.82 -> We have an ergonomic syntax and semantics.
1814.52 -> We have a fast and safe run time.
1816.86 -> And we have powerful static analysis tools.
1819.71 -> Because authorization is critical to security,
1822.5 -> we have built Cedar to a high standard of assurance.
1826.16 -> Using techniques such as automated reasoning,
1828.83 -> theory improving, and differential random testing.
1831.89 -> Now before we dive into the details of how we did this,
1835.88 -> let's talk about what it takes.
1838.28 -> What's challenging about building something like Cedar?
1841.01 -> And why we decided to take on this challenge?
1844.43 -> In order to build a robust authorization solution,
1847.55 -> so a language and a runtime,
1849.74 -> you have to solve three big problems.
1852.71 -> The first problem that you have to solve,
1854.21 -> the core challenge, is designing your language.
1856.94 -> In particular, deciding what constructs
1859.4 -> to include in your language
1861.29 -> so that it is expressive enough
1863.72 -> for policy authors to say what they need to say
1866.66 -> while at the same time being restricted enough
1869.75 -> to allow us to bound performance latency
1873.56 -> and to provide static analysis tools.
1877.64 -> Some choices here are obvious, right.
1879.74 -> You probably don't want to include loops
1881.09 -> in your authorization language.
1882.77 -> If you include loops,
1883.94 -> you're not gonna be able to bound authorization times.
1886.67 -> Right and in the worst case,
1888.35 -> policy evaluation may not terminate.
1890.48 -> Some choices are less obvious.
1892.31 -> For a language to be useful
1893.66 -> it has to include some sort of an aggregate data type.
1896.15 -> Right, so think lists or sets.
1898.28 -> But what data type can you include?
1900.08 -> And what operators it provide in those data types
1902.75 -> is going to determine your ability to write tools
1906.08 -> that can reason about policies automatically
1908.93 -> and prove properties that users care about.
1911.72 -> Such as, that a policy doesn't allow, never allows,
1915.5 -> an access to a private or sensitive resource.
1919.16 -> Okay.
1919.993 -> So suppose that you have done this right.
1922.04 -> You have chosen the right constructs.
1923.51 -> You have constrained your language appropriately.
1925.91 -> The next thing that you have to do
1927.17 -> is actually build a language.
1929.39 -> Authorization is critical not only to security
1931.94 -> but also to performance.
1933.65 -> So your engine has to be both fast and safe.
1937.13 -> And safety here means
1938.45 -> that it has to correctly implement the semantics
1941.12 -> of your language.
1942.23 -> You know, the spec that you're giving to your users
1944.3 -> and that they're relying on.
1946.97 -> Some choices here are obvious too.
1949.07 -> For example, you don't want to build your language
1951.44 -> in a lower level language like C.
1953.24 -> All right, your engine language like C.
1955.73 -> The reason is that C will give you speed,
1959.03 -> but it's gonna be very hard to prove safety.
1962.33 -> On the other hand,
1963.41 -> you probably don't want to build your engine
1965.57 -> in a high level, purely functional input language
1968.9 -> of Ethereum improver.
1970.58 -> If you do that you are gonna be able to prove safety
1974 -> but it's gonna be very hard to get good performance.
1976.73 -> So how do you get the best of both worlds?
1978.77 -> How do you build your engine so it is both safe and fast?
1982.34 -> And finally, even if your language is well designed
1985.61 -> and your engine is safe and fast,
1987.92 -> it is still possible for people to make mistakes
1990.77 -> when they're translating their intent
1993.08 -> into policies in your language.
1995.3 -> For example, you can write a policy
1998.21 -> that's actually okay.
1999.043 -> It does the right thing on most inputs.
2001.51 -> But on a few small corner cases
2003.76 -> it does the wrong thing.
2005.35 -> It either permits access when it shouldn't
2008.08 -> or it denies access when it should.
2010.6 -> Now to find those corner cases, conceptually,
2014.11 -> your static analysis tool has to explore an infinite state.
2018.67 -> Okay.
2019.503 -> So the set of all possible requests that could happen
2022.42 -> and the set of all possible states of your entity store.
2026.35 -> How do you write such an analysis so that it's fast.
2029.53 -> It can actually reason all this infinite space
2031.78 -> and it's precise.
2033.4 -> All right.
2034.233 -> So hopefully this discussion has convinced you
2036.4 -> that you shouldn't build a new authorization language.
2041.47 -> So before we built Cedar
2043.84 -> what we did is looked at the space
2046.15 -> of existing authorization solutions
2047.83 -> to see if we could reuse one of them.
2050.56 -> What we found is that they fall broadly into two categories.
2055.36 -> In one category you have languages and engines
2058.45 -> which are very expressive.
2059.68 -> They let you express arbitrary authorization models.
2062.32 -> So you can, you know, instead of sticking
2064.72 -> with a standard of one RBAC or ABAC,
2066.73 -> you can define your own and encode it in these languages.
2070.96 -> Now that's cool.
2073.03 -> But the problem is
2074.32 -> that because they're so expressive,
2075.7 -> you can't back performance and you can't analyze them.
2079.09 -> On the other hand,
2080.41 -> you have a class of languages that are very fast.
2083.65 -> They're extremely performant.
2084.97 -> And in principle, it'll be actually fairly easy
2087.34 -> to analyze them.
2088.75 -> The problem is that they're not expressive enough.
2091.45 -> They will let you write RBAC rules
2093.637 -> and some other flavors of RBAC.
2095.257 -> But you can write ABAC rules.
2097.75 -> What was missing in the space
2099.43 -> was the language like Cedar
2100.9 -> that balances these competing concerns
2103.06 -> of expressiveness, performance, and analyze-ability.
2106.78 -> So what we're gonna do now is look at how we build Cedar.
2111.1 -> Starting with the language design.
2116.47 -> We build the Cedar language
2118.03 -> by working backwards for customer use cases
2120.58 -> to define three main requirements.
2123.01 -> I will illustrate what these requirements are
2125.71 -> on a yet another example of what Cedar can do.
2128.74 -> And in this case, I'm gonna use
2130.33 -> a cloud-based photo sharing app.
2133.36 -> In an app like this, a user like Jane
2136.42 -> might want to upload her photos to the cloud.
2139.33 -> She will want to tag them
2140.8 -> and she will want to organize them into albums.
2143.68 -> She also wants to share photos with individual users
2146.86 -> and groups of users based on how they're related to her.
2150.61 -> For example, Jane might want to say
2153.28 -> that all of her friends are allowed to access
2156.31 -> or see, view, and comment
2157.54 -> on all the photos in her arts album.
2159.67 -> They have this nature tag.
2161.8 -> And there are less than two megabytes in size.
2164.23 -> Okay and as you've seen in Mahmoud's example,
2167.02 -> Jane would do this for some UI
2168.73 -> and the application would convert
2170.56 -> these UI interactions into permission policy
2172.93 -> that looks like this.
2175 -> Now what does it take
2177.79 -> for a language to allow you to express things
2180.67 -> that are as different as a financial app,
2183.79 -> a photo sharing app, and a vet app?
2188.05 -> Right.
2189.52 -> So the first thing that we have to be able to do
2192.61 -> is we have to be able to let you inject
2195.94 -> your own datatypes into the language, okay.
2198.13 -> So bring your own types.
2200.32 -> Bring your own hierarchies.
2201.94 -> And bring your own attributes.
2203.83 -> All right, so the language allows you to do that
2206.23 -> and you can use your own types.
2208.09 -> So in this case, entities that make sense
2210.37 -> in your application.
2211.69 -> Albums, photos, and so on.
2213.55 -> And you can reference entities in your store
2216.91 -> by their identifier, right.
2218.5 -> Which takes the form of the type name.
2220.6 -> Enter the name of the instance of the type.
2222.97 -> This is gonna be some opaque QID in real life.
2225.43 -> We're showing nice QIDs on the screen here
2227.17 -> so you can read things.
2229.75 -> We allow you to use this in operator
2232.45 -> to navigate the hierarchies.
2235 -> Okay.
2235.833 -> So the in operator determines whether the thing
2238.68 -> on the left hand side is a member
2240.82 -> of the group on the right hand side.
2242.26 -> This is how you express the RBAC rules.
2244.69 -> And finally, we also allow you
2246.91 -> to bring your own attributes, of course,
2248.5 -> and to access them within the policy
2250.3 -> using this dot operator which is going to be familiar
2252.52 -> from a language like JavaScript or Java.
2255.43 -> So that's our first requirement.
2257.26 -> We let you.
2258.093 -> So these entity,
2258.926 -> these application specific entities, hierarchies,
2261.82 -> and attributes are first class core concepts
2265.69 -> in the language.
2268.12 -> Now the other thing,
2269.5 -> the other requirement that we have to satisfy is
2272.23 -> in most of our customers applications when we talk to them,
2275.02 -> they told us that these attributes are coming from a variety
2278.05 -> of third parties, right.
2279.46 -> So think about a photo sharing app.
2281.14 -> Maybe the photo data is coming from user devices.
2284.41 -> So various kinds of third party sources.
2286.9 -> But usually these are structured
2290.5 -> in some sort of exchange, data exchange format,
2292.78 -> like JSON, okay.
2294.4 -> So for you to be able to express
2296.8 -> your attributes naturally in our language
2300.34 -> we support aggregate data types.
2304.03 -> In this case the set is the aggregate data
2306.52 -> that we support.
2307.57 -> And nested records.
2308.74 -> So you can nest things arbitrarily the same way
2310.75 -> that you would JSON block.
2312.7 -> Your mental model should be against Cedar, my JSON block,
2316.36 -> and it just runs.
2317.193 -> It understands how to navigate this, what attributes are,
2319.63 -> and so on.
2321.46 -> The final requirement,
2322.347 -> and is the one that Julian mentioned as well,
2325.03 -> is that the language had to be simple to read and write.
2328.84 -> This is both for the purpose of authoring policies
2332.08 -> and auditing policies.
2334.12 -> You shouldn't have to read a manual
2335.65 -> in order to understand what a policy says.
2338.53 -> We accomplish or we satisfy this third requirement
2343.69 -> by organizing our policies into two parts.
2348.19 -> An RBAC rule followed optionally by one or more ABAC rules.
2353.44 -> So the RBAC rule here is shown in green.
2356.11 -> So this is the head of the policy and the scope
2358.18 -> and the only thing that can appear in the head of the policy
2361.93 -> are these hierarchy constraints, okay.
2364.03 -> Using the in operator and the equality constraints.
2366.88 -> That's the only thing that can appear there.
2368.8 -> You constrain the principle action and resource
2371.44 -> using equality or in.
2373.69 -> And if that's all you need to say.
2375.64 -> That's your RBAC rule or are you done?
2379 -> If you need to constrain access or permission some more,
2382.3 -> you will use an ABAC rule.
2384.1 -> And you can use any number of them.
2385.45 -> And here I'm just showing one.
2387.28 -> What goes into this ABAC rule,
2389.77 -> or we also call it a condition,
2392.5 -> is an arbitrary Boolean expression in the Cedar language.
2396.34 -> You can think of this as a pure functional subset.
2400.87 -> Loop free, no side effects, no mutation
2403.69 -> of a language like Java or JavaScript.
2405.85 -> So that means you get all the constructs
2407.62 -> that you're used to, right.
2408.58 -> You get and, or, nots, conditionals,
2412.48 -> and the operators on your primitive data types.
2416.89 -> Now another thing that you can put inside of this condition,
2419.65 -> but I'm not showing here,
2420.97 -> is also hierarchy constraints and equalities.
2424 -> Which brings us to the obvious question.
2426.64 -> If I'm allowed to put hierarchy constraints
2429.37 -> in my ABAC condition, as well as my RBAC condition.
2432.67 -> What is the point of splitting the policy this way?
2435.19 -> Right?
2436.023 -> Why didn't I just give you
2437.83 -> this alternative hypothetical analytics syntax
2442.18 -> for expressing policies in the language?
2444.49 -> Any guesses?
2446.439 -> - [Audience Member] Readability.
2447.61 -> - Yes!
2448.443 -> Wow.
2449.276 -> Fantastic.
2451 -> See?
2452.41 -> So the first answer is readability.
2455.47 -> We actually ask our customers.
2457.33 -> We presented with bot syntaxes and said,
2458.777 -> "Which one do you want?
2459.61 -> Which one do you like better?
2460.443 -> Which one do you find more readable"?
2461.83 -> They prefer the structured one.
2463.27 -> And the reason is
2464.68 -> with a structured one you can just glance at it
2467.02 -> and see what's going on, right.
2468.25 -> It's in RBAC rule followed by an ABAC rule.
2470.62 -> With an unstructured one,
2472.12 -> you as the human being has to have to pretend
2474.338 -> to be a parser, right.
2475.66 -> You have to visually parse the policy
2477.49 -> and then extract parts which are ABAC rules
2480.31 -> versus the parts that are RBAC rules.
2482.32 -> So that's one reason.
2484.84 -> The second reason is that if you write your policy this way,
2489.91 -> your policy evaluation is going to be much more efficient.
2493.99 -> The reason is that we designed Cedar
2496.39 -> to have a property called slicing.
2499.12 -> This property means that it is possible
2502.18 -> to correctly evaluate an authorization query
2505.09 -> against a small subset of all the available policies
2509.11 -> and all the available data in the data stores.
2511.48 -> And get the exact same authorization result,
2514.84 -> including errors actually.
2516.61 -> Including error messages
2518.86 -> that you would get if you were to evaluate
2521.47 -> this request against the full store.
2524.5 -> So what we do under the hood is
2526.99 -> we're using the head of the policy to create indexes
2530.32 -> which allow us to quickly compute the policy slices
2533.41 -> and make fast authorization decision.
2535.93 -> So the syntax is designed so that it nudges you
2539.17 -> to our writing policies that are more readable
2541.51 -> and more performant.
2544.93 -> Okay so that's how we design the language in a nutshell.
2548.74 -> And let's talk about how we build the engine.
2553.39 -> From the point of view of client of Cedar.
2555.97 -> You know, AVP is the client of Cedar.
2558.7 -> It takes three inputs.
2561.01 -> The request.
2561.97 -> So principle, action, resource, and context.
2567.4 -> Entity slice.
2568.42 -> So some part of your entity store.
2570.19 -> And a policy slice.
2572.59 -> And it passes these inputs
2574.21 -> to a module called the Authorizer.
2576.58 -> The Authorizer runs the evaluator
2579.85 -> on each of the policies against the other two inputs
2582.58 -> to obtain one of three results.
2584.44 -> True, false, or error.
2586.09 -> And then it combines the individual policy results
2589.51 -> into a single authorization output, allow or deny,
2594.01 -> along with the diagnostics that you have seen
2596.08 -> in the previous slide that Mahmoud showed.
2600.37 -> Now the first question that we are gonna tackle
2605.14 -> is how does Cedar achieve speed?
2609.22 -> Okay, we have to achieve both speed and safety.
2611.08 -> So let's tackle speed first.
2613.36 -> We achieve speed by building Cedar in Rust.
2616.69 -> Rust is a high level language
2618.67 -> with the performance and memory characteristic
2621.46 -> of a low level language like C.
2623.56 -> Okay.
2624.43 -> Cedar is blazingly fast.
2626.59 -> To give you an idea,
2627.91 -> a typical authorization request involving hundreds
2630.55 -> of policies and thousands of entities
2632.59 -> takes less than a millisecond.
2634.93 -> Cedar is very memory efficient.
2636.97 -> The reason is that Rust doesn't have a garbage collection
2640.48 -> or any kind of a managed run time.
2643.27 -> The Rust compiler proves
2645.07 -> if your program compiles in rust
2646.72 -> it type checks the Rust compiles proves that it's free
2649.69 -> of memory safety errors.
2651.55 -> Okay.
2652.383 -> So by building in Rust, we get speed and memory safety.
2656.71 -> But how do we get correctness?
2658.87 -> Okay.
2660.04 -> How do we know that this engine that we implemented
2663.04 -> is actually correctly implementing the semantics?
2667.51 -> Well, a programming language alone can't give you that.
2670.03 -> So we have to do something extra.
2672.34 -> The extra thing that we did
2674.23 -> is developed a formal executable specification
2678.13 -> of the Cedar semantics.
2680.62 -> This specification takes the form
2683.14 -> of a very small, high level functional program.
2687.4 -> It's only 500 lines of code.
2689.68 -> You can sit down and read 500 lines of code in an hour
2692.38 -> and convince yourself that it corresponds
2694.93 -> to our English spec.
2697.45 -> Now to check that
2699.16 -> this reference implementation matches the production engine,
2702.37 -> we use a technique called differential algorithm testing.
2705.4 -> This involves running both engines on millions,
2709 -> and millions, and millions, and millions of inputs
2712.06 -> until you achieve coverage of the production engine.
2715.39 -> And you make sure that on each of those inputs,
2717.88 -> the two engine produce the same authorization result.
2721.06 -> This gives us high confidence
2723.19 -> that the production engine matches the semantics
2725.65 -> of the language as embodied in the reference engine.
2729.13 -> Now here's a really cool part.
2731.56 -> Our reference engine is built in Dafny.
2734.95 -> It's about 500 lines of Dafny compared to
2737.86 -> about 10,000 lines of Rust.
2740.38 -> Dafny is a language programming language
2743.59 -> that has a built end tier improver and a verifier.
2747.61 -> What that means is that for all those properties
2750.91 -> about our language semantics, such as slicing,
2754.87 -> we can construct a mathematical proof
2757.3 -> that those properties hold.
2758.95 -> And the Dafny verifier will mechanically check
2762.04 -> that our proof is correct.
2763.45 -> That all the logical steps that we specified
2765.73 -> do in fact hold and the antecedent leads
2769 -> to the consequence, right.
2770.65 -> Some example properties that we have proved
2772.45 -> are shown on the slide there.
2773.53 -> So the properties that we care about
2775.12 -> have to do with security.
2776.77 -> So for forbid, permits, overrides permit, right.
2781.3 -> We have proved that for any policy
2783.4 -> that you can throw at us.
2784.66 -> Doesn't matter what it is.
2786.04 -> We've never seen it.
2787.06 -> For any inputs to that policy.
2789.97 -> Policy set.
2790.99 -> If there is one that says forbid this access
2794.68 -> and the other one says permit this access,
2796.48 -> forbid is gonna win.
2797.71 -> Okay.
2798.55 -> So that's the key security property we have proved.
2801.628 -> A key performance property we have proved
2803.47 -> is that slicing appropriate dimension before
2805.48 -> that it's actually okay to make this authorization decision
2808.6 -> against a small slice based on these indices
2811.15 -> as opposed to the entire store.
2813.55 -> So by using Dafny
2816.94 -> and by using Rust and differential testing,
2819.28 -> we have high confidence that our production engine matches
2821.71 -> the semantics and that our semantics
2823.9 -> has the properties that we care about.
2826.72 -> So this brings us to the last part
2828.79 -> which is the static analysis tools
2830.62 -> that you as the policy author get when you use Cedar.
2835.526 -> If you sign up for ADP today,
2838.51 -> you will get out of the box a powerful static analysis
2842.08 -> which we call validation.
2843.7 -> The validator is based on an advanced type system.
2848.38 -> It's for the check that your policy
2849.97 -> is free of many kinds of runtime errors
2852.4 -> including, of course, type errors.
2855.16 -> What we are working on right now,
2857.17 -> so this is a sneak preview,
2859.48 -> is an even more powerful kind of analysis
2862.75 -> which is based on satisfiability, modular theories,
2865.72 -> or S and T solving.
2868.69 -> These kinds of analyses allow us
2871.21 -> to answer universal questions about policy behavior
2874.6 -> and to do so quickly and precisely.
2877.78 -> In particular, if you give us a property
2880.39 -> that you want to make sure your policy satisfies
2883.3 -> on all possible inputs,
2885.13 -> the underlying server can quickly search
2888.88 -> an immense state space, okay.
2891.04 -> Infinite in the worst case.
2893.14 -> And make sure that your policy does indeed satisfy
2896.02 -> the property on every single point in that space.
2900.16 -> If you have this underlying infrastructure
2902.95 -> you can build very powerful policy authoring tools.
2906.37 -> Let me give you an example.
2908.71 -> We can build a set of tools,
2910.78 -> we call them an equivalence analysis.
2913.39 -> Actually, we've already built them.
2914.35 -> We prototype them.
2916.48 -> That allow you to refactor and optimize your policies
2920.53 -> with confidence.
2921.88 -> What does this mean?
2923.47 -> This tool will make sure that any changes
2926.83 -> that you make to your policies
2928.48 -> will not either increase or decrease
2932.02 -> the set of things that are allowed.
2933.61 -> Okay, so you're not gonna mess up.
2934.99 -> The tool will tell you if you mess up.
2936.82 -> So here's an example.
2938.47 -> What you see on the slide there,
2939.82 -> and I'm not expecting you to read those policies by the way,
2942.76 -> is a set of three policies
2944.38 -> from that photo sharing application example.
2947.8 -> Now this is the kind of state
2950.32 -> that you might get in
2952.24 -> if you're iterating on a new app, right.
2954.19 -> So you have different developers figuring out
2956.5 -> who needs to be accessing what
2958.27 -> and they just keep on adding permissions
2960.07 -> and, you know, until things work.
2963.43 -> So now imagine that an auditor is coming tomorrow.
2968.02 -> So these developers have to refactor this
2970.78 -> into something that the auditor can easily examine
2974.11 -> and convince themselves that he's doing the right thing.
2977.29 -> If you have time to stare at this
2979.24 -> for maybe the next 20 minutes,
2980.56 -> and we don't have that much time,
2982.87 -> you would see that these policies
2985.15 -> are actually saying something very simple.
2987.91 -> These policies are saying
2989.17 -> that a principle can view or comment
2992.14 -> on any resource that they own.
2994.03 -> It's fair enough, right?
2994.99 -> I can see my own stuff.
2997.09 -> Or on any non-private resource
3001.98 -> that is a JPEG or a PNG photo
3004.47 -> that's owned by somebody else.
3005.91 -> Okay.
3006.743 -> So that's all these policies are saying.
3010.08 -> Now let's say that we want to refactor this
3012.6 -> and replace it with a much simpler form policy
3015.06 -> that kind of follows the structure of this English sentence.
3017.61 -> All right.
3018.443 -> So here's an attempt to do that.
3020.678 -> And it sort of looks like it's following the structure
3022.187 -> of the English sentence, right.
3023.55 -> It's saying that allow things when resources
3026.16 -> and principals account.
3028.29 -> When the name has the given shape
3030.51 -> unless the resource is private, right.
3032.94 -> So it sounds like it should be right.
3036.36 -> We can ask the analysis to check
3039.51 -> whether this is true on all possible inputs, right.
3042.39 -> So what the analysis is going to do
3044.49 -> is going to examine the universe
3048.39 -> of all inputs that could ever come into your policies
3051.69 -> and see if these two policies sets agree on all of them.
3055.83 -> In this case, the answer is going to be no.
3060.12 -> I made a subtle mistake when I did this refactoring.
3063.45 -> And the analysis is going to synthesize a concrete witness.
3067.77 -> A test case, right.
3069.69 -> A request and an entity store such that
3072.66 -> if you were to run this request against
3074.94 -> this synthesized entity store,
3077.34 -> you would see that the old policy set permits
3081.36 -> this request while the new policy set does not.
3084.96 -> Okay.
3086.13 -> So it's found a bug.
3088.59 -> Now there are many ways to fix this particular bug.
3091.8 -> I will show you the simplest way
3093.66 -> which is to just split this into two policies
3096.3 -> which correspond to the two clauses
3098.25 -> in that English sentence that I have.
3099.9 -> The first policy deals with the case
3102.51 -> when you own the resource
3103.83 -> and the second policy deals with the case
3105.63 -> when you don't know the resource.
3107.34 -> And when we run the analysis again
3109.56 -> on these two sets of policies.
3111.12 -> It's going to say that it's okay and you are done.
3115.05 -> Now equivalence is just one
3118.92 -> of example of the kind of policies that...
3123.03 -> Or the kind of analyses that we can do
3125.4 -> with the underlying technology
3127.05 -> that we are currently building for the Cedar language.
3129.837 -> And if you have ideas for the kinds of analyses
3133.44 -> that you would like us to build
3135.72 -> and run your applications,
3137.43 -> please do reach out and let us know.
3139.11 -> We would like to hear about it.
3140.49 -> And with that, I will hand it back to Julian.
3146.468 -> (crowd applauds)
3155.01 -> - Thanks Emina and Mahmoud.
3157.44 -> So that wraps it up for the day.
3159.12 -> For us anyway.
3161.34 -> You can see here a QR code
3162.9 -> which will take you to the landing page for the service.
3167.01 -> There are a number of resources out there online.
3169.56 -> There's a website that we've set up
3172.32 -> that is dedicated to the language itself
3174.9 -> with a set of tutorials and an overview of the language.
3178.47 -> And we'll be obviously publishing even more resources
3180.84 -> as we go forward through the rest of this year
3182.79 -> and into next year.
3185.04 -> Thanks again very much for coming.
3187.02 -> We launched a gated preview.
3189.33 -> So if you have a project in mind
3192.51 -> that you would be interested in using this service
3195.63 -> to try out and build against,
3197.4 -> then sign up for the gated preview.
3199.86 -> And the three of us will be in the answer room afterwards.
3204.48 -> If you wanna follow up individually with any questions.
3207.15 -> We'll hang around for a while.
3208.8 -> If there's anything you'd like to chat about.
3210.81 -> So again, thank you for your time
3212.01 -> and enjoy the rest of the show.

Source: https://www.youtube.com/watch?v=k6pPcnLuOXY