Modernize authorization: Lessons from cryptography and authentication

Good afternoon, everyone. Thank you for joining us here in Las Vegas for re:Invent. Uh my name is Eric Brandwein. I'm a Distinguished Engineer with the Amazon Security team and I've spent a lot of time with a lot of authentication and authorization systems across Amazon over the last 16 years.

And hi, I'm Neha Rta. I am an Applied Science Director in AWS Identity, working on externalizing authorization solutions and bringing something called automated reasoning and probable security to these systems.

So our jobs are hard. We live in this miracle world where we have invented these machines that do exactly what we ask them to do and they do these tasks without complaining millions and billions of times approximately perfectly so perfectly that it's a rounding error, but they're dumb. We've got such tools but they lack common sense. They do exactly what we told them to do, not what we meant to tell them to do. And the net result is that most days, I feel like I'm stuck in the fire swamp surrounded by traps and peril on all sides, a single wrong step. And I'm doomed

The way that we handle this as an industry is via encapsulation. If I gave each of you a bag of transistors and a soldering iron, how many of you could build a working CPU could write an operating system, could write a compiler. These are tools we all use every day. You don't have to know the whole stack.

Take the most quotidian application, a web browser every single one of you uses this every day. How many of you really know how that thing is laid out in memory, how it uses processes and threads. The only way that we scale, the only way that we build non-trivial things is by letting someone else write the building blocks and then using those as our foundation.

The trick is that you have to know when you need a building block and you need to pick the right one. The first time I encountered this, I was working at UUNET, which was a large internet service provider and the University of Oulu in Finland, which I had never heard of before. This released a set of vulnerabilities in pretty much every S and MP implementation S N MP is the Simple Network Management Protocol. And if you dealt with network gear back in the day, you used S N MP, I worked at an ISP I knew S and MP and honestly, it wasn't until these vulnerabilities dropped that I even knew what a N one was.

Do you know what a N one is? If so my condolences, it stands for Abstract Syntax Notation One. And it's a format for specifying and serializing records as and mp is built on top of asn one. And it turns out that at the time, pretty much every single asn one implementation was rife with security problems.

We built our network on top of a management protocol and that management protocol was built on top of the serialization format that I had never heard of. And it totally ruined my week. The only way to scale is to use ever larger building blocks, but you have to choose them carefully.

So here's an example from Amazon back in the day, we had these data centers and in those data centers, we had a bunch of web servers and out on the internet, we had a bunch of customers in order to have a viable business. Those customers need to be able to talk to those web servers, but the customers are outside and the web servers are inside. What's an online bookstore to do. The answer is a fancy type of firewall known as a load balancer. This is a hardware appliance. It sits on the perimeter of the network and it routes requests from the internet to our internal servers.

Now, a client can show up on the internet, it can send us a request, the load balancer will pick one of the back ends, route the request to the back end and we're good. More requests show up more requests get routed and we're in business. Of course, you're not just going to send your credit card to Amazon in the clear text over the internet. Like it was a much kinder gentler internet back then, but even back then sending credit card numbers in the clear was a bad idea. And so we had to offer what was then called SSL Secure Sockets Layer today. It's called TLS to our customers, at least for some pages. This is the way the internet used to work, sign in and check out and things like that were encrypted, but everything else wasn't.

So the way we did this was by terminating SSL on the load balancer. This was great. It made SSL someone else's problem. None of our service teams needed to deal with it. They checked the box when they created the VIP, they got SSL like we were done, customers got the happy lock in their url bar. It was awesome. We've built on top of an underlying building block, so we're good.

And then there was a series of papers that started coming out. This is one of my favorites. Like anytime you can use the XR symbol in the title of a paper, it's a good paper. It disclosed an attack called the BEAST attack that made it possible to decrypt sessions that used block ciphers. SSL v three block ciphers much, much, much, much faster orders of magnitude faster than you should have been able to and so this paper came out, there were a series of other papers that followed it and what seemed like overnight SSL v three and TLS 10 which had been the standard for years were suddenly no good anymore.

So it seemed like overnight we just flipped the switch and turned them off in the real world. It was messier for a while. The internet moved to RC four which was a stream cipher. It didn't suffer from the problems of block ciphers. But then it turned out that RC four itself wasn't awesome and we switched back and, but that's fine. We've got to go change our config, let's get it done.

So looking at this diagram, the only thing we've got is the load balancer there in the middle. That's where we're terminating SSL. So let's go turn off the broken stuff. Wait a second. What is that going to mean to our business? What is turning off the broken stuff going to do? The obvious question to ask is what was negotiated, the client and the server, talk to each other. There's a handshake and they agree on a protocol version in a cipher suite that they're going to use for this session. So that's great. But that's not actually the question that we need the answer to because this just tells us what would not have been negotiated that way. Had we changed our configuration? What we actually need to ask is what was offered we need to know what is the set of clients that would no longer be able to negotiate a connection with us if we turn certain things off.

So great, let's go get that data. The only thing that our load balancers would tell us it was a little one bit flagged. The session is or is not encrypted. It wouldn't tell us cipher suite. It wouldn't tell us protocol version. It certainly wouldn't tell us what was offered. And so we can't even answer the first question not to mention the second question.

This led to some interesting deployments and some nail bitting moments, but we made it through to fix this. We built something that we call relay. This is actually the TLS terminating chunk from our public services and we package it up and for deployment on our physical servers back in our data center, it's deployed on every server and it handles TLS termination right there on the box.

Now, whenever a customer makes a request, the load balancer still handles, handles it, but it handles it as a, a TCP connection as a layer four connection, it doesn't terminate TLS, forwards it onto the back end and then that web server negotiates TLS with a client. And so this has all sorts of benefits. First of all, it's end to end all the way from the client to the web server has some nice security properties. It turns out we were getting better performance because now we're terminating TLS on a commodity box and it's following the commodity curve and every generation is getting faster rather than the proprietary hardware that was in the load balancers. And because we wrote this thing, we can get all the data we need and even better if there's data we need in the future. Again, we wrote this thing, we can make it cough up whatever information we need. This is a glorious place to be right end of story.

Of course not. It's security in 2014, a serious implementation bug in the most commonly used SSL and TLS library went public. It was called Heartbleed. I started diagramming this out and then I remembered that Randall Munroe did a much better job of it than I ever could. So here's most of an xkcd comic. The idea is that there's this thing called a TLS heartbeat. It's just a check to make sure that the session is still alive. The client says, hey, are you still there? If you're there? Send me back this message. In this case, Meg is asking for the word bird to be sent back, send me back this message. It's this many characters long for and the server is like, ok, here's your message back.

The problem is that we're passing a message and a length and OpenSSL wasn't validating that the message length and the lengths that were passed were the same. And so you could ask for a response up to about 64 kilobytes. And so you could send a tiny little request with a long length and the server would just take the next 64 kilobytes of memory and return it to you. You could not turn this into ad os attack. You could not turn this into code execution. You could not turn this into privilege escalation, but it was trivial to exploit. It was incredibly fast. And so you could just go fishing in memory and on various servers across the internet, this became a sport briefly. Uh people were getting private keys, they were getting session cookies. This was a big deal like this was not a good thing to have floating around the internet.

And you ask like this is so easy, like how come they didn't just check that the lengths were there? Well, it's there on the screen. Can you see the bug? I've done a little bit of surgery to make it fit, but it's really the original code. And so C is a tough programming language in general and this in particular is pretty dense C that right there. That's the line. This is telling the machine to copy payload worth of bytes. That's the length from the pointer pl to the pointer bp. However, that payload is taken straight from the request that came in off the wire without doing any validation on it. This code was added to OpenSSL by an experienced developer who had a long history of strong commits to the project. It sat in the code base for years before anyone figured it out. These things are hard to get right open. SSL happens to be the library that we used for TLS termination in ELB and Relay and a bunch of our other services we were impacted, our customers were impacted. We scrambled. It was, it was a long night, but in about 24 hours we managed to get everything patched deployed out.

Um but up until this issue broke, I've never even heard of TLS. Heartbeats. It turns out that none of our services relied on them. None of our customers used them. Like we didn't need this code to be correct. We needed this code to not exist. OpenSSL was a building block we chosen and it was time to re examine that choice. Our response was to build our own TLS library called s2n it's publicly available.

It's intentionally minimized to only have the functionality that's needed to serve a web service on the internet. It doesn't support TLS heartbeats at all. They're just not there when we built it. We did multiple rounds of review with external parties, cryptographic researchers, et cetera. And we actively engaged with the security community. One of the reasons that we open sourced it was so that other people could benefit from it, but we also open sourced it because we don't have the hubris to think that we're smarter than the entire internet. We wanted the scrutiny. This is how we terminate TLS today, both on what remains of our physical network and on LB and our other services.

Great Eric, fascinating story. What does that have to do with authorization?

That story wasn't actually about SSL and TLS. It was about choices we'd made about the building blocks that turned out over time to be less than ideal so far. S to N has been ideal, but we'll see what the future holds. So everything we build is built on top of something else, operating systems, languages, protocols. We're standing on the shoulders of giants and none of the problems are trivial. But the core problems, the ones that make your service secure or available or performant, those things need reliable building blocks. And the choice of a building block is not a one time thing that building block is going to be a part of the foundation of your service. It's going to be there for the life of your service. You want building blocks that are going to stick around and evolve. With the times often there are multiple choices for how to consume that building block.

You can download S to N right now and you could build your own TLS termination. And if you had particularly unusual requirements, that might be the right thing for you to do. But now you're responsible for scaling and for patching and for every cryptographic paper that comes out like you've taken on a significant burden of ownership or you could use OB and delegate a lot of that to Amazon and consume it as a service rather than consuming it as code. Neither of those is the right answer. There are tradeoffs. Either way you should consider the consumption model as you're choosing your building blocks. And even if your service is simple today, it won't stay that way over time.

Authorization is non obvious, hard. And so Neha is going to tell you about some technology we've built for authorization and whatever you do. And again, we think that what we've built here is pretty interesting, but make sure that you invest and you take the time to make good choices in your building blocks.

So talking about building blocks, authorization is a key building block similar to cryptography. But what's different about authorization is it's more accustomed to each application than cryptography. Nobody says, hey, I want my own version of TLS for this application. There's one S to N and that works very much across a lot of applications. But when it comes to authorization, we have our customers say I have these types of users, I have these types of resources. I have these types of access that I want my users to have on these resources and they are unique and specific to my application.

So we solve this for AWS. We launched AWS. IAM in 2010. Most of, you are probably aware of it, use it on uh on an everyday basis and we designed this common building block to do authorization across all AWS. Now, before we had, IAM, we had something called uh ALES on S3 buckets and objects. Uh they're still there. We also had a couple of services that had their own variants of authorization, but with IM, there was a single building block that we could have across all of the AWS services. It provided a common set of principles. AWS principles. It provided a common set of actions that were AWS actions and common AWS resources. But this was for AWS and customers asked us, hey, we want something as a common building block for our authorization for this. We built Cedar. It is an authorization building block for your applications. You can customize Cedar for your principles for your actions and for your resources.

I'm gonna pause here and talk about what does it mean to have a common building block for applications and what are some properties that you'd want? So imagine you are a developer uh working on a banking application and you want to do a simple thing. You want to ensure that your CFO can grant access to other people in your company to do to access certain accounts. And you can imagine variants of this application in whatever domain you're working with. What happens today mostly is you have the authorization logic that is intermingled with your application logic and the banking application suddenly says, oh now you need a mobile version. What are you gonna do? You can copy all your authorization code for that mobile version, but they may not actually be implemented in the same programming language. So now you're doing a lot of work you're getting inconsistency.

How do you actually know tho those two match when you have a common building block, you get consistency because the permissions are stored are decoupled from your application logic. The next thing is you get scalability when you start writing an application, wherever you start a few 100 users, a few 1000 resources. But as your business grows, your application grows, this us bank that we are talking about is expanding its business to europe and asia. In addition to growing its number of users, number of resources. Now there are new regulatory requirements and there's scale in two dimensions, the scale in terms of the number of users and scale in terms of the complexity, it has to scale to the different types of use cases that your business and application is evolving to a common building block will provide you that scalability.

And this is this is another very interesting one. If you have every application running its own bespoke authorization logic, it's extremely hard for security administrators to figure out, hey, what does bob actually have access to across all of these applications? And there is an incomplete view there's often blind spots with a common building block with a common lingua franca security administrators can now have a complete view of who has access to what this is very similar to what you get from. IAM when you talk about access to your AWS resources.

So some of you might be wondering so why don't we just open up? IAM for customers. IAM was designed specifically for AWS a pisa ws resources and AWS principles. It would need extensive changes to support custom apps and for a system that's called trillions of times a day, that's a tad bit tricky. But also it's important to understand what does Cedar do and what does IAM do. Cedar is focused on application level permissions for customers. It puts customers in control of the principles, the actions, the resources and you can write, decide to write principle centric policies or resource centric policies. While IAM is focused on AWS infrastructure, the principle are AWS principle roles, users, the actions are AWS actions get object, put object run instances and the resources are also AWS resources. They have specifics. Uh AWS resource has an R and EC2 instance has an R and an S3 bucket has an ARM which is why Cedar and IAM coexist but serve two very different purposes.

I'm going to dive a little bit more into the differences. I want to look at what's common between IM and Cedar and what's different between them and I want you to notice there's a lot that's same and there is a lot that's different. We aren't starting from scratch but we are also not just shipping you a copy of IAM. We are keeping the fundamental design principles of IM. Same, deny by default, deny trump's allow. And these are important principles for security. These are important principles for a good building block. It makes the policy language secure and easy to use. But where we are diverging from IM it's very intentional. It's in the area of control. AWS controls IEM resources, principles and actions you control in Cedar your principle, your action and your resources.

So how did we leverage our experience in? IAM when designing Cedar, the Cedar language design took a security first approach where we decided to prioritize security over expressiveness. The language is what I call expressive enough for the different authorization, use cases, role based access control, uh attribute based access control, but the language has no loops, no recursion, it's not touring complete and that is by design.

So we also formally how do we know it's actually secure this building block and we use a technique in automated reasoning to formally prove properties about the security. And with this proof like great, it's great to have proof, but we also rigorously tested that it actually works in practice.

So how do we ensure that Cedar is easy? We provide it by tools we provide you tools for policy validation to ensure that when you author policies in Cedar that you do not make mistakes, there are no errors, there are no typos.

So I'm gonna talk about each of these a little bit. I'm going to kick off by looking at a few examples of what a Cedar policy looks like. Now, the first policy allows a administrators to view client records and schedule appointments. This is what we call a permit policy since it's granting permissions. The other type of forbid policy is the dual of this a forbid policy and the structure of a Cedar policy is that each policy has a principal action and resource. In the first policy, the principal must be a member of the office admins user group and the action that they can perform scheduling appointments and viewing records you can see in the policy that follows and that the resource is a client and it needs to be a member of all clients group.

Now, the second policy allows primary doctors to view client records and refer them to specialists. This is a again a permit policy. What's different here is that there is a when clause on the policy, this praises extra limitations on when the policy applies here. The principal must be a primary doctor of the client. So not any doctor can refer the client or view the client record. It's only the primary doctor and i talked about it being expressive enough. The first policy is an example of a resource based access control because authorization is based on the role of the principal and the resource. The second policy is attribute based access control since it relies on the attributes of the resource here that the fact that it's a primary doctor, that's an attribute of a doctor.

The same policies will apply across multiple implementations of the same language or different applications that you have in your corporation or that are implemented across different platforms. Now, the banking application that we were talking about that suddenly got a mobile version. If your policies were Cedar policies decoupled from your authorization logic, they would work out of the box for your uh access control. That's the power of a building block that you have here, you get consistency.

Now we talk about design by secure. How do we know that it's actually secure this building block and we prove mathematically certain properties about our language.

Now denying access by default, this i believe is an important guardrail and security. When you're designing something you can decide whatever you want to do, you can say uh deny like it could be the opposite of it. Permit by default. Nothing stops you from doing it. So why are we saying do the deny by default? It's to make clear what you have to do for somebody to actually have permission. It's very clear and the thing you have to do for somebody to grant to have permissions is write a policy. It will never happen automatically. In fact, that's the level of assurance you want in your building block another security property deny trump's allow, allow security administrators know for certain that if there is a deny policy, no matter who adds a permit policy somewhere, it's never gonna be granted. It's another guardrail that you have.

Finally, there's another one order doesn't matter another security property. You don't have to worry about which policy was added first, which was added in the middle. What was added in the end here? I like to again, think about the flip side. Imagine order did matter. You would have no way of knowing how your authorization works. So this is the kind of design principles that you want in a building block. You don't have to worry about the fact that your authorization is deterministic.

The last one that I want to talk about is if you have validation in your policies, you're not going to have runtime errors. And this is the one i'm gonna talk about a bit more, but this really allows you to have assurance that your end user experience is gonna be good and your developers aren't gonna be frustrated.

So I'm gonna talk a little bit more about policy validation. This is, this is gonna be interesting. So, Cedar has something, it's something called, it's typesafe. So Cedar at run time knows every type, whether it's a boolean or a string or a long of every principle resource and attribute and it does run time checking when it, when it's evaluating a request, it it checks all the arguments have expected types. If they don't have the expected type, then it can lead to a runtime error.

Now, here's the key. How do you know statically that runtime errors will not exist? And Cedar provides you this ability to do policy validation. Eric was talking about tools, tools are as smart as you make them. So you want a good tool that tells you, hey, there are gonna be no runtime errors when somebody invokes this request.

Now, how does, how does Cedar know about it? Uh you can have a very well formed policy that follows the grammar of the policy, but these policies may still have typos, they may have errors, they may have type mismatches and in fact, Cedar on its own doesn't actually know whether the policy is free of errors or doesn't, it just doesn't. So you have to help Cedar do that. So Cedar needs information about your application and the way you provide, Cedar, that information is through something what we call a schema. It, it's the way that you provide the correct names and types of your principles, your resources, the attributes and even the relationships between them. Uh what's the hierarchy of employees, what are the job levels? And here you can have an employee who has an attribute of name of type string a job level of type long. Well, you're not gonna run out of job levels anytime soon and an optional attribute, number of laptops here, the action, remote access is a valid operation for a principal who is an employee. So this is a way you're telling Cedar about your application what's valid for your application because Cedar doesn't know otherwise.

Now we're like, ok, great. We're gonna start generating policies because we have all the tools we are ready to go kind of looks. Ok. Let's, let's, let's ask, uh the Cedar validator. First, I was like, wait, the first, here's the first error, remote access is applicable to only principals who are employees and here your principal is unbounded. So you'd have to, just to fix this error, you'd actually have to save a principal uh an employee. Ok. The rest looks ok. The number of laptops that's, that's a long. So it's ok. But mm, there's no such thing as laptops in your application and it goes on. Hey, this is a name, this is a string. And of course, this example just to demonstrate the type of things your validator would tell you. But the real power of policy validation is long before your policy is actually running in production. You have an idea and you don't have to go scratching your head later. Why is the statement not matching? Why is there a run time exception? Some customer filed a ticket that they don't have access to. And like now your support engineer is debugging and cutting in ticket to your engineering team. But with policy validation, you are a step ahead of the game.

So we told you we do these proofs. How is it that we actually do these proof? We use a tool called Daphne. It's a verification of air programming language. It's actually open source. So you can go and uh try uh try using Daphne, there's actually even a little tutorial. But what Daphne allows you to do is you can write code and specify the properties about the code and it will prove it. It'll say, hey, do these property hold under all possible scenarios and it has a built in automated reasoning engine that does it automatically. So we do this on the Daphne model. But our implementation is actually in Rust because we want it fast. It's an authorization engine, the results need to be fast. So to rigorously test it, we have a technique that we use called differential random testing that takes a lot of tests that are generated from the Daphne model and executes it on actually the Rust implementation to ensure that the model matches the implementation. And this gives us a high degree of confidence in the correctness of the implementation that's in Rust as well.

So what do you get? Cedar is open source. It's uh it has the Apache 2.0 license includes the Cedar language spec the software development kit and it actually provides you these libraries uh which are also open source for authoring and validating the policy. And you can use the authorization engine to authorize the different access requests. Again, it's uh we have this RFC process. So if you have requests, uh you feel free to go on there, ask for it. There is a Slack channel engage. We also have a lot of different other material I've told. Ok, you said that there's a lot of different material. How do you get started?

There's some easy points. We have cedarpolicy.com. Of course, we are back in the .com boom area. It provides you a playground. There is a little tutorial that walks you through uh Cedar and think of it as a puzzle. Like even if you don't want to do authorization and if you like puzzles, if you like a little uh thing, go to Cedar uh cedarpolicy.com. Take the, just do a tutorial. It's a, it's, it's a website. It's simple. Uh and if you're like, hey, this is great. It serves uh my purpose. I wanna learn more. Read the documentation. It'll, it'll tell you about the different language constructs. If you're ready to dive in, check out the code, we have a GitHub page. And um if you want to get started using it in your application, there is uh a Cedar policy crate. All you have to do is add it to your cargo file. So if nothing else go to cedarpolicy.com and try out the tutorial.

Now, you've heard of the tutorial? You want to use it. Eric's talked a lot about the need for having good building blocks and after evaluating your needs, you're like, yup, i need this as a building block. So how do you get, like, how do you actually get started for reels? And there's two different paths. One's green field where you're building something from scratch and the other is where you have something running and that may have been running for weeks, months, years, maybe a couple of decades. And there's different now. It's, it's not rocket science that the green field door is gonna be a bit easier. But what is it that you have to do as you're going through the design phase of your authorization uh of your actual application? That's when you think about your authorization construct as part of your design of your application. What are your APIs that will inform, what are the actions in your permissions, your identity set up? Who are your principal? Who are your u what are your users will inform your principles? What are the attributes of your users that are relevant to the application will consist of the attributes and conditions in your policy? How are they related? What's the hierarchy of your identity? Your storage design will inform your resource hierarchy structure. So there's a lot of parallels as you think about it are you, are you storing it flattened? Are you storing it in a database? Why are you storing it in a database? Like are your resources files? Are they you know, files within a folder? Are they folders within a folder? And all of those will again come back and inform your resource structure. This works completely in harmony. So when you come to the point of actually writing a policy, the authorization constructs will just fit together in because by this time you'll know who are my principles, what are my resources? What types of access do i have? And what are the key relationships?

Now, let's get to the other path. This one's a bit harder, not unsurmountable, but definitely a bit harder. And it's, it's good to admit it, this is harder. It's gonna take time. Now before we like think about it, we have to think about the journey of where an application runs up. I'm building a personal digital library. This is how it started. It's multi-tenant, it's gonna be the next big thing. And i wanna add some access control. It's very easy all about, hey, if the person asking for access is uh is not the owner, then you know, no dice. Super easy. Simple if statement, that's it. Single if statement, that's all my access control needs.

Well, turns out as my application evolved, there were administrators and i do want the administrators to have access to all the books. Ok? But that's ok. That's it. It's gonna be only one more if statement just one more. I'll quit tomorrow. I promise. Oh, now we are adding, you know, our security teams are asking us to add multi factor authentication. We are up to three rules now and it's almost getting hard to see how they're related to each other. And this is a, this is a code that fits on one screen and if we had to say, does order matter are the permissions nested, what conditions are actually necessary to grant access. And we'd have to sit there looking at the code thinking it through and it's hard to figure out.

So in any real world application, it's going to be like exponentially harder. It does truly get worse as your application scales to new case, new use cases that requires permissions features and notice how the application code has actually just quickly slid off the screen. Here's it, here's the three step process. It's not an easy path, but you can get started. The first step is just log your current authorization. The second is start writing policies and start comparing the results of your policies with the results of your current authorization. You're not doing anything with the policies, but this is for you to learn the authorization constructs. And third, when you're certain that you have the policies that match your current authorization behavior, flip the switch. So log compare and use.

Now logging is really important because it gives you a view of what's happening today. And for applications with spread out code, often it's really hard to know what is the code doing. So logging will allow you to audit, to understand what is happening today. When, when is access being granted, when should it be granted? What are the conditions? It's being granted, who's not being granted access? And step two is now you start writing policies and you have code again. You're not using this policy for anything yet. You're just writing them and comparing the results of the authorization from your policies with the results that you're getting from your authorization code today. Just compare a b think of it as like a b testing. But uh the Cedar policy is not doing anything and prepare to be surprised. You will learn about your system. You learn about the authorization as you go through this process. What you thought wasn't there will suddenly pop up.

But this is the process that you can go through to discover and really create. What is it that my uh application should be doing in terms of the authorization?

Step three. When you get to a fixed point, when you get to the point where it's like I know these are the policies for my application, you can flip the switch. So you've gotten rid of all that code that was in your application and look your application code is back on the screen and all your policies separately nicely. Not, no intermingle gives you the consistency. Uh it'll scale, it'll provide you the authorization tools.

So log compare and use there is hope for doing it for brownfield application. This is not a simple path, but you gotta get started now. So I've talked about a basic building block. Eric talked about s two n and you could do it, you can download it, you can run it. Um but you still have to do a lot on your own. Like you have to actually run cedar. You have actually uh keep it up to date. You have to do manage the policies.

So for you to not have to do that, uh not just use cedar as a building block, but rather use it as a prop. We gave, we built a managed service. Amazon verified permissions. So it takes cedar and provides a fully managed experience for your manage uh for your permissions management. You can store cedar policies centrally have low latency with millisecond processing. Uh you, you have one place for policies across all your different applications and it provides you the tools to help build guardrails around your authorization.

So i wanna take a minute and take a look at what are the benefits of cedar versus what are the benefits that having an aws service provides you? And how, what are the benefits of a bp at the bottom layer are the benefits of cedar? We talked about those the policy language is common. It's easy to use designed with security force principles. Mathematically proven, the middle layer is using verified permissions. You get benefits of of aws you use. I am for who can create policies like the policy management store, who can update, delete policy management. The service a ps are managed by im like all the other aws services.

Now you can use cloud trail for auditing your authorization request. So the logging that you were doing in your application, you can just send a cloud trail and now you get consistent logging and audit capabilities. Like all other aws services, you can use the standard aws stk again, like all the other aws services on top of it, the very top verified permissions does give you additional benefits. It manages stores all your policies, schemas does your propagation of policies and you can use a vp and cedar with any identity provider.

But there is an easy button if you're using amazon cognito. And most importantly, it's an ecosystem of authorization tools. Now, while you may build your own authorization logic, it's not in your benefit or not uh to your advantage to be building tools for your permissions management. And this is an area where having a common, using a common building block allows you to leverage an ecosystem of tools around that building block. It's an area we will keep continuing to invest in.

Now with amazon verified permissions, right? I said what do you get, if you are uh running cedar on different hosts? When a user makes access to different hosts, you have to ensure that cedar, the same version of cedar is running. You have to ensure that if you've created a policy, it gets uh updated to the one making a request on a different host, the standard distributed system stuff. The one thing uh you, you get out of the box with a vp is all the policy management. Your user will make requests to the different host but your host will all have, they have to do is called a vp as i mentioned.

While you can use verified uh permissions with any identity provider. The thing you'd have to do today is when the client makes a request with an authorization token, uh your application has to unpack the token, uh extract the user and other attributes from that identity token and call is authorized. So that is when will check the authorization. The easy button approach with amazon cognito is when the client makes a request with a cognito token, your application can call is authorized with token and vp does the work of unpacking the token into standardized principle and attributes format and check authorization.

While we provide this with amazon cognito today, we are going to keep expanding the different identity providers. We support for the easy button. My favorite set of tools is the authorization tools. We talked about schema and a vp provides you a visualization of what actions can be performed by which principles and even how the different principles are related, how the different resources are mapped onto each other. How, what's the hierarchy? And this can be very useful when you have a large number of actions, different types of principles and resources. This one's a simple example.

So you can kind of flow and everything maps to a client. A way to think about it is this can be a tool as you are designing your authorization. In greenfield applications, you have a visual element. Is it how i want it to be? Is this the hierarchy i want? Is this the relationship i want. And in brown field applications as you are discovering the right authorization construct, the visualization can really help tell you how which direction are you moving in the right direction? Wrong direction. Are you making progress, not making progress about learning about your own applications?

So we said i told you a little bit earlier that cedar gives you policy validation, it only works. If you use it just that little caveat, you gotta use it for it to work. So why is that hard? Because you gotta remember to use it like you may remember to use it but will every other developer in your company remember to use it? So in a vp, you can require validation and then you don't have to remember use it. You don't have to ha have your other developers remember to use it. So it's called strict mode. If you turn it on. And now if you try to create a policy or update a policy that has errors in strict validation mode, you will not be able to either attach a policy, create a policy or update a policy before fixing those errors.

It provides you this guard this tool that suddenly all you had to do was click this radio button in, in the service and now none of your developers have to remember to use policy validation. So great policy validation gives you no errors. But how do you actually know that the permissions are what you intended them to be? How like a bp is? Well, it can be great. Still won't be able to read your mind or read your intention or be able to figure out what you actually want your permissions to be.

So to help in that, it provides you a policy test bench. You can create these example text scenarios can eric schedule an appointment for joe. You can put, put that in in a simple thing and a bp will go and evaluate that request against all the policy that you have stored and come back. And if the answer is not what you expected, it'll tell you which policy granted or denied the uh request. You can go and add the policy to grant access, update the policy to remove test again. This is a great iterative testing process to for you to know. Yes, the permissions i want are the permissions that are uh in my policies.

Again, you still have the same journey. But now with the tools, you both your green field and your brown field journeys, those paths became a bit easier. A bp is like your buddy you have in your authorization journey. Ok. We're getting close to wrapping up. So go to the tutorial, write your first cedar policy. Go to the policy playground like it's a little think of it, your wordle thing, like write up uh write up cedar policy like you do wordle and when you're ready to integrate, just go to the cedar sdk for like, hey, i want to manage experience. You can go to the a vp console and start in a guided setup mode because again, there's no one click, turn on for authorization of your application. It'll, it'll walk you through how to set up, eric, what other advice do you have for folks on getting started?

So this was definitely an vp talk. But the reason that we think vp is so important is that it's a key building block for any interesting application. I've been bitten multiple times in my career by having building blocks that we assumed were solid, but which turned out to be less. So you can't scale unless you use these building blocks. But it's worth thinking about the stack of them on which your application rests. I've also been bitten by underestimating the size and complexity of a job. Often they start out simple enough and it's only the future complexity that turns out to be daunting. It's hard to see the future and to strike the right balance between cost now and cost in the future.

I told you this story of tls and ssl and all of the travails that we went through an important thing is that all of our customers and all of our services that were using b just got upgraded by the service team. We have an incredible team, their whole job all day, every day is to run that service. And so when harple happened, the services that were running on el b didn't have to engage the lb team, our crypto team, the security team, we engaged, we drove that as fast as we possibly could safely drive it and we fixed it for everyone.

So think about your building blocks. Authorization is non obvious complex. What i mean by that is that most people think that they can do it themselves. And it's only until they've actually gotten themselves in trouble that they realize that it's a, it's a big job. It's a daunting task. I tell you this not as someone who is brilliant who realized this a priority, but as someone that has dug the hole and climbed into it himself, think about the ones that you have, but also think about the building blocks that you should have the places where you have a job that can be delegated to a service to an underlying component. And again, authorization is hard. It grows over time and it's incredibly important that you get it right. Your customers are depending on you getting it right. And trying to work your way through the spaghetti logic of nested if statements is all but impossible.

What should you do for existing applications? What's the end state? How complicated is this thing going to get authorization tends to be intimately intertwined with the application we've designed cedar and vp so that they can be retrofitted. But the roi may not be there if you're building a journaling app where a user has access to their journal, no one else has access to their journal. It, it's this intensely personal thing. It may not be worth it. The juice may not be worth the squeeze if you're building an enterprise app where you've got legal hold requirements and all sorts of administrator access, cedar and vp might be the thing for you.

What is your service or your application look like when it's done, whatever done is. And for new applications, i would start. Now, if you have any sort of permissions model at all, i would use a vp on wednesday of this week. I'm giving a talk about a new feature we're launching in one of our a i services. And at this point it's a very, very simple permissions model, but the team happily used a vp when they built and deployed it. This made it easier for the team. There's a chunk of things they just don't have to build. They like the fact that their policies were separated out, they were easy to analyze. And it also meant that there were a whole bunch of questions they didn't have to answer during their application, security review. Our security team was like, oh, you're using a vp. Let me see your policies. That's cool. Let's move on. It significantly reduced the burden on the team and they know they're well set up for future complexity.

We don't know what that future complexity is going to be, but we know we're going to have it. And so even though it was super simple at launch, we still think it's a win and think through the life cycle of your building blocks, you're going to want to have a building block that's with you for the life cycle the entire duration of your service.

Uh thank you very much for your time and attention. If there are any questions, we're happy to field them.