We will start with a young person who has founded a company who concentrates on cloud centric. Let's call it that way. Identity management. We had a number of discussions over the last years, and I'm very proud to welcome on stage Patrick Parker.
Thank you very much.
Yeah. You've so Patrick, four seconds, you founded your company in 2004. Saidright
2004.
What were the challenges when you founded a company
Hiring talent, building that first generation product that would scale? That's always a startups first challenge.
We were lucky enough to not have the luxury of not being able to scale. Our first customer had about 600,000 identities. So trial by fire.
Yeah. Okay. So how many people do you have today?
50.
50. Okay. And customers
Over 400,
400
Customer over 450 people, huh? Yes. Yes. Many customers at international, lots of customers in Switzerland, Australia, all over the world. London.
Okay. Yeah. Interesting. You are going to talk about specifically identity and access manager in the cloud or for cloud based services as,
Right? Yes.
The challenge of authorization in Amazon and Azure specifically.
Okay. So thank you very much, very much yours. So the clickers
Here. Thank you everyone.
Okay, great. Okay. So my talk today is on how to manage authorizations in cloud services. We'll be focusing on Microsoft Azure and AWS
Me.
So as well, we're very well aware. It phenomenal growth. The rush to the cloud is going at even faster pace, recent numbers from Amazon, that there revenue in the quarter, 1.5, 7 billion, 49% Microsoft is growing faster than Amazon, but Amazon has a very, very significant lead, but Microsoft's numbers are very impressive. 62 million users on office 365, 50 million of those being corporate accounts.
And that only represents 10% penetration of their entire office installed base. So they have lots of room to grow, lots of room to, to get really, really large Azure, which is the backend platform services for office 365, over 10,000 new customers per week. And they have over 350 million users in Azure active directory. So two very large bohemus growing rapidly. They're real. The reality in it that we're all gonna be dealing with is how to best secure our resources in this completely different environment in the cloud.
So just a little flashback here, 2006, Eric Norland, maybe you might know him. He organized identity management conferences, but one of the debates going on in the identity circles was would we ever have single sign on what was in it? Why would the big companies ever be motivated enough to let one identity from another competitor be used for their services? So thankfully that authentication silo challenge has been conquered. Now you can single sign on into pretty much anything. So the authentication side of it, I think we've all done.
A very good job at that was, is one that is well known and we'd say has been conquered in many ways. It needs to be secured, but it has been conquered from the, the basic interoperability level. So what is the next frontier what's next is since we can't authenticate across these systems, it's easy to have systems, you know, proliferate cloud services, a mix of cloud on premise, many vendors into cloud, multiple vendors, actually recent surveys say that most organizations will be planning for 77% of them. A multi-cloud environment services spread across multiple cloud environments.
So a new challenge, a new frontier for how to manage authorization, how to audit it, how to have policies and procedures in place. How do we have a strategy for handling our systems as they become even more distributed?
So looking at the big players right now, these are the silos. This is the next silo that needs tackled. Each of these systems have their own authorization within them. Very little ability to have centralized authorization that you're, you're managing it centrally. The decisions are made centrally.
The policies are managed centrally and that they will consume it as they consume identities for single sign on. So this is really the large technological challenge, the hurdle, and a it's as important as authentication because authentication gets you into the system. The authorization is, is controlling, who really has access to what and how can we be sure that the proper people getting that access and that we're not granting it to the improper people.
So 20,000 foot view, one thing, you know, when I started getting into Amazon, AWS looking at their identity management services, we, we use that.
We also use Azure. We're actually a multi-cloud company is really getting my arms around. What are they offering? What is their intent? How does it fit into your strategy?
What, what are the, which facilities do they provide and how they do, they intend you to use it, which portion of the market are they attempting to capture? So you can plug that into what is the, the best solution using all the various components to secure my assets, either on premise and also in the cloud, how much of the cloud can I use to secure my on premise or how much of my on premise infrastructure is gonna be necessary to secure these cloud environments? So really where are they headed?
I can't speak for them from an internal planning perspective, but from using both of the services extensively, you could really see the telltale signs of what is their intent, which areas are they attempting to cover. And at a 20,000 foot view, just a super high level, Amazon, AWS, their identity and access management services are intended and well designed to manage AWS services. If you're to manage their virtual machines, to manage their S3 buckets, to manage all the various services that they provide, their, their identity and access management is designed to manage those services.
Microsoft on the other hand takes a completely different approach. Microsoft's intent. It's visible intent by the functionality that they provide is that Microsoft intends to manage access to all of your applications. So Amazon's focused on identity management for their services. Azure is focused on identity management for their services, plus everything else in your environment. So they're coming at it from completely different perspectives. They definitely have a different approach. They're pros and cons to both.
And I can't tell you where they're headed, but I can tell you where they are today. So diving in a little bit deeper, this is gonna be a little bit more of a technical conversation, but what do they provide given that their intent, Amazon, to protect their own services, Microsoft, to protect their services, plus your services, your applications on-premise and off what is the next level down?
So AWS, one of the, the misconceptions or one of the things that you need to get a handle on very quickly is that the AWS identity and access management has a user store.
It has users, it has groups, it has roles, but their intent is it is not an active directory replacement. It is not a, an identity as a service, a central directory that your users are all gonna be stored in. It's not a directory that your machines are gonna be joined to like an active directory domain for authentication.
It's, it's not what it's for the, the purpose is they don't really even recommend it to be used. Is that the intent really to have as few users in that directory as possible, it's really more about managing access to, to services as, as API identities, as partner identities, but it's not intent the intent, not that you're gonna stick a user in there and your applications are gonna use that as their central authentication source or their central authorization source.
And that's very apparent when you look at the published limitations, the limitations on the IAM user directory in, in AWS is that you can only have a hundred groups.
So we know right off the bat, that for authorization, not many use cases would, would be able to use just a hundred groups with that hard limit, a max of 5,000 users, 250 roles. So we see very quickly that it's its intent is not to be an active directory replacement, an LD replacement, or an identity as a service replacement. What they do offer in that realm is they do offer a new service called the simple directory.
And it is basically a SOMBA active directory clone. You can pay on a monthly basis. You can get the, the smaller, the large, and the intent of that is that to if you're provisioning all of these machines, these EC two instances managing passwords on every single machine managing authentication across every single machine is really a pain. So it gives you a simple, active directory. You can join your machines to it, just like an active directory domain.
It can, you can have an authentication directly into it.
So your active directory for Microsoft, the intent Azure's intent is really to manage everything your on-premise, your off-premise. They wanna be your single central source, but what are some of the limitations? What are the misconceptions? Probably the most commonly commented on an asked question on the, the news groups and discussion boards is how do I join my machines to this Azure active directory domain?
And it, it does not support that that's not its intent. It's, it's not a replacement for your network operating system, active directory on premise. Really their assumption is that your on that you will have an on-premise active directory that will be integrated via some synchronization mechanism into your Azure active directory in the cloud cost on both Azure, AWS IM is free. That's intended to support their services. So this makes complete sense. If you wanna use the simple ad, it's very cost effective. If you're provisioning lots of machines, you can have them automatically join that domain.
So it makes, you know, the domain membership, a single user accessing the system very cost effective Azure active directory has a free edition, but for almost all of the features that you'd want for identity management for authorization, you would require the premium addition, which does have a monthly fee per user.
So drilling into a 10 foot view, really what, what are, what are these services? What are they made up of AWS contains users, as we saw, it's not intended to be your user directory for all of your users.
They're more just users that are going to maybe log in and do a few things in a console or their identities that are coming in via Federation. It has roles. It has policies which control access, which we'll take a look at. And it has identity providers. So you can put plug in your external identities into this system and not have a user in their directory to pass in an external identity. And it will have rights to access the services.
So looking at the diagram, their basic constructs are that you can have users, users can belong to groups in AWS.
You can have roles, machines connect as act as roles. So your, your C two machines that are running as part of your elastic, scalable cloud application will act as a role which controls the access they have to the various services. Can they upload files? Can they access, you know, different web services you might expose. And of course, users can be assigned to policies. Policies can be assigned to roles. Policies can be assigned to groups. Now the policies are where all of the permissions they're, it's very aback based mechanism. It kind of looks like Zamal except it's not XML based.
It's J based. It's the JavaScript object notation. So it's much more brief, a lot less to look at a little bit simpler to look at it. Some might say the role, the machines can act as roles. And probably the, the most interesting thing from an enterprise planning perspective is that roles can be assigned policies, which control the access, but the roles can be plugged in and passed in from your enterprise identity management system.
If you set up single sign on your system, that where you manage policies, you manage authorization can pass in, will this user should have this role in AWS, and you're not managing a user in AWS. And that role will define their access.
Here's an example of a policy. They have a policy builder, but the general layout of the policy would be access to their service. And which actions, someone that this policy applies to may perform for that service.
And then against which target, which folder, which bucket, which other item and the policies are very, you can have queries are very flexible, but again, the ideas that you're gonna manage your users in your system, and they'll be passed into that system with a policy attached that defines exactly what they have access to, which is evaluated at runtime. Here's an example in my environment, I created a policy called server administrators.
It, it has a full access for machines attached to it. And it's limited that only Patrick can have that policy. So you can limit it by user, by group, by attribute. When I log in, if I assume this role, I have to activate the role, which is in our back concept.
Then I am limited to the permissions assigned to that role. So you can manage it centrally, but in the, when I'm logging in, I can act as that role active directory, Azure really it's, it's the Microsoft model they've had all along. It's very group centric.
So you're going to be managing groups, plan on managing groups, whether you're thinking those groups, whether you have a tool to manage the groups, the groups in Azure are still the key and the intended recipient of the access rights. Azure has it broken down to where roles, similar concept. They define the actions that you can perform against the Azure services.
It's not, you know, use it for anything that you define for your applications, it's against their services, but which actions you may perform against which services and those that access is assigned to roles, which, or groups and it to be, to be in a role, you really need to be in a group. So here's a quick look of owner role right now. There's a very limited set of roles. You cannot define your own roles.
That's due down the road, but the roles are designed to allow you allow or deny actions against specific resources, which they have a whole scoping of, you know, your tenant, this service type, this, this group and these resources. So you can assign the policies, but again, mainly to manage your access, your, to their services,
An example that they give of how to use Azure to manage your applications. A typical example would be that you would be just doing a group check.
Your applications would have security written into them, which would demand that the user be to have access, to see this widget, to perform this action that they would have to be in one of these specific groups. They also support using application roles that you define.
But again, it's very group centric to be in the application role. Really you're gonna have to be in an Azure active directory group to get that role. And it'll do just a very basic check. This is the, the simple approach is not the best approach where you're just checking or you're writing in your code.
You know, if you're in this role, if you're in this role, if you're in this role, you have access to this because then when you go to audit it, you have to look at the code. Then when you go to change it, you have to look at the code. And there's no real capability of seeing really who has access to what if they get into this group, what are they getting access to do?
A recommendation would be to move to an external authorization system that you can ask more fine. Green questions at runtime can. In this example, the per the current person use Luke Skywalker, light saber.
So not, can they use any light saber, can they specifically perform the action use for that specific light Saer and you're managing it externally. You get the auditability, you get the manageability. So you could, I could have the right to use Luke Skywalker's light saber, but a gentleman in a crowd might have the right to recharge it, but not to use it. So you get those realtime decisions. You could change those policies on the fly.
So going back to just really pulling it out, what are the recommendations given the intent and what they provide? Definitely you want to plan for multi-cloud.
Most organizations will have resources and applications or services that span both. So you need to know that you're going to be managing. You need to be auditing across clouds, split your subscriptions, do not use one, the same subscription for your dev, for your test, for your production. You don't want accidental things to happen, or someone's testing something. And it happens against production, centralized authorization decisions.
So one key takeaway would be that neither service today offers a central authorization management platform that can manage both of them, or that can manage both of the, those services and your application. So plan for using what you already have, or looking into something else for centralized authorization to get the manageability for these key systems require multifactor authentication on the case of Amazon, just some specifics.
So the no running outta time is the best practice is definitely to manage authorizations in your system, federate and pass user's roles and not manage it in AWS.
You do not want AWS to be another authorization silo. And then for Azure, since it's all about the groups, make sure you have your group management nailed who can be in groups, dynamically, getting in people into groups and why they're in those groups, try to tie back group membership to something that makes business sense as far as what, which job functions people perform. And is this the appropriate access, which will net into groups at the end. That's all I had.
Thank you very much. Thank you here for a minute.
Okay, Patrick. So first question.
I, I under, I, I was told by so many people that Microsoft office 365 is actor sitting on Azure. Now you're telling this is, this is not the same, right? It's
It is sitting on Azure, your office 365 is sitting on an Azure active directory instance. That's correct,
Which has specifics.
So we,
There has very specific limitations as far as the authorization. So if you look at office 365, it presents a new set of hurdles.
You have, you have the roles which are available for Azure to use for management within their preview management. Porwal those are not the same roles that apply to who can manage users or mailboxes in office 365 in office 365. You have the office 365 admin console, which has three main roles for managing users, a global you have access to everything, a user. And I forget the other one, a limited one, and they are there's their scope is everyone. So there's there, isn't a currently an ability to, to say you can manage users for this department or this business unit.
And then the exchange console for office 365 mailboxes to perform the exchange actions has its own R back that it brought forward from the on premise exchange. So when you throw it on together, you have many consoles, many role models, all very different and nothing that really pulls it together to manage it from one essential
Spot. Okay. So you mean your, your primary recommendation is it's not going to work only with these tools. You need an additional platform that consolidates these different
Approaches. Exactly.
You need some something to pull it out to where you can manage across platforms and have auditability to say who could manage these key boxes in office 365, who can, who has access to these key applications that are hosted and using Azure, cuz there's, there's not a facility right now that really provides the viewer, the, the management of that externally to that those systems will use.
And one last question, you mentioned that at Ws, Amazon is actually using something like Zal on Jason. Yes.
And we've seen a number of standards or, or implementations of previous XML based standards now being kind of translated to Jason. Yes. Do you think this is something that's going to be used by other platforms as well? I
Do.
I, I, I see it as a very good model. I mean, it's, it's, it's the developers nowadays. XMLs kind of heavy. It's very verbose. When you look at it, it's easier just to look at JS O there, lots of good developer tools to, to create, take JSON object and pull it into code and into memory and to write it back.
So it seems to be the way things are going and the authorization using the JS O documents gives you a lot of flexibility, like Zal to write in the conditions that have very conditional logic that's evaluated at runtime and using the context of what your IP, which form of authentication did you use. I mean, things that you couldn't evaluate, not in the moment.
Okay. Yeah. Thank you very much again. Thank
You. Pleasure.
Thank you.
