Overcoming Enterprise Entitlement Barriers by Externalizing Authorization

Good afternoon, ladies and gentlemen, welcome to our KuppingerCole webinar. Overcoming enterprise entitlement barriers by externalizing authorization. This webinar supported by Oracle speakers of today are myself Martin KuppingerCole and of from Oracle before we start some general information and some housekeeping. So could bring a call as an Analyst company, focusing on enterprise it research advisory, decision support, and networking for it professionals through our subscription services for our research, through our advisory services and through our events.

Our main way is the European identity conference, which is co-located to the cloud. 2011 conference. Both conferences will be held in May, 2011, 10th to 13, so may in Munich, and they are definitely the place to be with more and 100 speakers and a lot of very interesting people to meet also from the audience side. So really a very good place to, to meet the experts from the industry, as well as from the end user organizations around identity management, GRC, cloud security, and related topics. There are also European identity awards where you can nominate your projects.

So if you have a project run, then it's idea to nominate for this award Umpo sponsorship opportunities, still some few open, and you can register for sure directly for the conference. So regarding the webinar itself, you will be muted central.

In fact, you are in fact muted center, so you don't have to care about these features. We control them. And so that's nothing which would what you would have to do. We will record the webinar. So the recording will be available usually by tomorrow and QN a will be at the end. So you can ask at the right side of your screen at any time, you'll usually pick them at the end of the web webinar into a Q and a session. In some cases, we also might pick a question before if it's very appropriate for what we are talking about in the webinar.

I always recommend that if you, if a question comes to your mind, you trust, enter the question so that we have comprehensive set of questions available. When we are ready to start a Q and a session, the agenda into three parts, likely any webinar of cooking a call, the first part will be the Analyst part done by me, Martin Kuppinger. I will talk about entitlement management, market status and trends, the role OFAC and the real world. And so what really mean for, so how do you do these things?

And second part that will be done by superly for, he will talk about real world use cases for externalizing authorizations in heterogeneous environments. And like I said before, the third part will be the Q and a session where you can handle the questions. And as I've said before, if there's a question that comes to your mind, just Android using the questions to go to webinar control panel, which you'll find at the right side, if you street, okay. So let's directly start when looking at at application.

So one things where I'm, I'm doing sort of evangelist for now is what I would call externalizing security out of applications, avoiding hard, coded security. So that's one of the things. If you look at today's application development, we still have a situation where the, a lot of applications are built, which have their own user management, which throw passwords in the birth case unencrypted, which do their own authorization, have their own business rules built in, have their own audited auditing.

Don't have any interface to, to do this sometimes for sure you have some or other things, but in many cases you still have hard coded security and hard coded security is from my perspective, a very painful thing. It's hard to change.

And so we, we should think about how can we externalize security out of applications and all layers. And these layers are in fact, the four typical, a so four A's. We have an identity access management, our administration authentication authorization auditing in all areas. It's about externalization. It's about also standardization. So we should have in our organization, one consistent view in identities that might be also physically distributed. But at the end of the day, we should have a situation where we say, okay, we know this person that's that, that is information, which is correct.

At that point of time, it's not necessary one directory, but there should be something where we could rely on, on where applications could work against the same as authentications should be flexible. It should be what we really need. We should shouldn't have too much. We should have sort of at least a reduced sign on this.

The number of signs we have to do, not per application, but relying on, on existing application on reduced doesn't mean unsecurity means it could be very strong because we have only very few things to focus on the appropriate ones, authorization, consistent policies, reliably enforced policies for access controls, business policies. So who is allowed to do for an approval of an, an insurance above 50,000 Euro, who is only allowed to do it below 50,000 Euro. So things like that, these are business rules. They should be consistent.

They should be centralized and reliably in first, and they should be based on reliable information and auditing as well. I think we should have, that's an area where, where sea vendors are earning a lot of money these days because they try to address the problem of distributed non integrated logs and other things. The better way would be to, to be able to provide information to central log, to, to provide information to central event management system, all that type of stuff. So it's very obvious. We have to need, we have to need to standardize in that area.

And the, the big problem behind this is there are affect too many places for, so we have different directories, but somewhat covered by provisioning. So we have also to build, let's say the infrastructure to do that. That's another part of it. It's one part is that's my main part today will be talking about the applications. What do we have to do from an application perspective, but for sure, we also have to look at the other side. So what do we need as an infrastructure? We need something where we could rely on an administration. We need something where we could rely on authentication.

SSO might be work on federations, increasingly popular. We have a lot of things to do authorization. In best case, we have some silos where we have sort of a little bit of centralized authorization, but that's in fact, this real challenge that will be my main topic today. How could we integrate a silos of administration up development, this respect to authorization, auditing a lack of standards, still some workarounds, like I've said before, seen tools and other things, things. So why should we do this? Why should we externalize security at all? Layers out of applications?

I think it's pretty obvious in many cases, but I nonetheless want to just go through the list of things, which I think are most important that the most important drivers there, one is software orders are in many situations, illegal requirement. They are requirements sometimes ignored, but it's a requirement. So that's one of the things we have and to do software it's much easier to, to have a set of services for security, which we know that are our security. We trust, check the use of these services, not every part of the applications.

So if we come in, in, in software audits, look at only the, the, the way we use services, then it's much easier to do an audit than to go through the entire security code. If it's standardized, it's easier to do that managing risks. So having a standardized security model for applications, for sure reduces risks because we rely on a standardized infrastructure for these things. We can easier meet compliance requirements, so controlled access of sensitive data by different processes, reusing these services much easier when we do it was standardized services.

We can reduce the cost of software development because building or adding security to the code, isn't cheap. It costs a lot of money. And we know all that, that in many situations that is done, let's say at the end of the software development process, because it's necessary and that it's done in some way or another, not necessarily the best one costs, a lot of money doesn't really make sense. So to achieve the target of having not only business process, but secure business process, we have to externalize security.

We have to build on standard security services and we have to look to achieve and to end security. So what does it mean? And to end security means that we know this is Martin coping or where we do the things for. So this is we, we are acting in the context of Martin Cooper or for example, or any other users.

It's, it's sort of a context of a use that might be a role because he's the role, a group, another constraint, an attribute, anything derived from a user or the user itself, but you need to have end to end security. One of the, the big problems. And it's an example. I have used many, many times in presentations and webinars and so on is if you look at the typical three tier applications, you have a browser, you have an application server, so, or application server in the middle, and then you end up with a database server.

And in many cases, the application, those, okay, this Martin K, and then it uses a technically used to access the database. There's some return set of results, set of information, some records, and then in the code, it's defined, okay, if it's Martin K, because he has that role, then showing all the, that product of the results set. The problem is this is very obvious. It's hard coded security. It's not end to end security. The database doesn't know anything about the user. That's a problem. So there are risks, coded security, limited accountability.

Who's really using this information, the obvious security risk management issues with technical accounts, which you look at all the initiatives around privilege, account management, several of them are related. Technically use. We have a lot of webinar recordings around privileged user identity, whatever management available at our website, where you could just do a replay and look at what I've been talking about or telling about that. And you have the compliance risk. So if you don't know who really accesses the data, you have problem with a lot of regulations in that area.

What is the main reason why it's the siloed it organization? In fact, so we have infrastructure, including security. Maybe we have also infrastructure and security separated in different silos, and it's even worse. We have software architecture, we have software development. So we have an infrastructure or an organization, which is segregated in different silos and they don't talk that much. So they don't work with each other. They don't talk with each other.

And for retrospective, externalization is one of, of the, let's say bigger challenges because it's about how can you bring these different parties to work with each other? And from our perspective of, we'd like to externalize security from an infrastructure and security perspective, it's about providing services, which are easy to use for developers. So making it easy for developers, really providing them interfaces, which are easy to use and which are adequate for the way they are developing software, but for sure they are different, different issues to deal with.

So, so how do do we do it? So, so what of broaches? We can do it at a gateway. So if you have so, so why security gateway a gateway, something like this, then can, you can use it. You can also do it at a, at the level of the web access management. You can do it at the level of duplication or the service. So very close to end to end security. The problem there always is how do you interface from the application to your system, which provides and the authorization status. So how do you do it in a way where you don't have that much lock in within your application?

Some cases it's probably the best way to do sort of a wrapper. So, so using a very simple interface, and then the, let's say using the specific interfaces of the Pega systems you like to, to use afterwards.

So, so building a rubber where you can then easily change the services you are using there, the container that would be definitely the best approach for the future. So really security enabled infrastructures. We have some things going on there.

So, so in some areas you have the ability to, to really get information about a current use user with a lot of attributes directly using a standard glass with standard method and properties of the container. Some very few application environments. I think that's a, that's a trend and that's probably one of the best ways to do it.

However, that's more sort of the long term, least the mid term approach to do so we have different things. And I'm, there's no doubt about that's sort of a complex thing, a complex challenge to, to decide on how do we best interface. So how do we make it very easy for developer? How do we have a wide lock in and how can we do it from a technical perspective also from the maintenance aspects and all the other things.

And so that's, that requires some, some, some thoughts, but so we got, we are gone through, through projects with customers, developing such concepts, and I definitely can assure you that it's feasible. It's definitely feasible today. Sometimes it requires a little bit more of thinking, but with the tools, and we will hear some more about tools later on available today with the infrastructures available today, things are increasingly easy to solve, and it's not that it's rocket science or it's something which is far away in the future.

Something you definitely can do today and which that you definitely should address today. You should really start building your concepts in that area, because that really helps you to manage your security and your software development, traveling channels at least once related to security in the future. So how do we manage these policies then? How do we describe them consistently? And first and consistently, that's a very interesting question. Sometimes we will have specific policies for specific areas, and sometimes we can use a standard policy. How do we map the different levels of policies?

So we have the very high level business. So we need a policy approach, a framework where we go from our high level business policies down to the more technical and sometimes very granular policies. We also need tools to support this. How do we manage also this dynamic approach compared to our relatively static approaches we have today? So it's also a problem of how can we really understand what happens in such environment? I think that's also something which is definitely feasible, but it's a change. And we have to, to really think about it first, how do we move from tactics to strategy?

So first of all, think about how to do it focus on standards, how can you manage it? How can you make these things easier and define your application security, standard and interfaces. And that's a very important thing in a way which started if you, if you go many, some of your respect, we have an application with own users and policies. We sometimes have it today. So identity management, we addressed the situation that we said, okay, we can distribute the user so we can have the same users everywhere.

We then are also able as Federation to rely on a central side of users and where we should end up, we should also have central side of policies. So that's where we really should go forward users and policies for access control, for business policies.

All these things used in standardized ways by applications not having it per application, which in fact means that in, in our infrastructure, so where we have our, our let's call business, our E P CRM, the applications and business service exposed by then, which we are using in our application infrastructure, the same way we should use our as and identity services with the underlying entrance and the policy and identity stores. And one of the very, very important things. And one of the most important things which we will address in that this webinar are things around organization.

So from an application perspective, it's about working with standardized services. We need standards. We need to decouple applications from identity and, and, and security. And it makes it also easier to go forward towards cloud services. Important role was in this place exactly the extensive access control market language, which is a standard for separating the policy management and the us authorization decisions from the enforcement that the application level itself there, a lot of elements.

We also have a lot of recurrings of webinars around UMEC was it's a standard which helps us in the area of interability. It's sort of a common denominator, but it's a very technical standard. So it shouldn't be the, an application developer uses it should be something, or also not the thing which used for the, the, the all parts of the policy design. It's more something which works in the background. You need things before that.

And you need also to look at this as a solution, which that not only covers the, the, the service orient applications, where you say, okay, I have my applications, I use my security services. You also should look at how it does it work with the authorization management of SharePoint, content management, Porwal outcome management, Porwal related to profile system security for your standard applications, for databases, for your cloud services.

So when you think about this, then think big, think about how can I manage authorization for everything I have in best case, you won't necessarily be able to roll it out for everything at the beginning, but your strategy should cover everything to do that. We have a lot of tools out there. So we have policy servers, we have entitlement management servers, we have fine grain authorization systems. We have some provision systems with somewhat limited capabilities, but some, some basic capabilities of some website service security systems with limited capabilities. So we have a lot of technology.

We supports us in defining policies, which supports us in interfacing with the applications. So the, the ones we are developing and the standard applications to support all these entitlement management things. So there's an increasing market out there. And in these days, I think this market is really becoming sort of, of public.

So it was more sort of a hidden secret in the industry for some years, right now it's definitely gaining a lot of momentum because more and more companies are really starting to use it, not only tactical for a few applications, but to use it in the standardized strategic way. That's what I, what we strongly recommend to do when looking at these winners. And one of the winners will be talking right after me. There are some criteria for choosing winners, one of the most important maturity and scalability of the solution. It's really the solution.

So is the solution mature is the solution scalable? That's a key thing because when you run time, authorization relies on these central systems where you say, okay, I ask them for the authorization. Then they have to be, make sure they have to be scalable. They have to be fast. They should support exactly, but not only exactly. So things like RB and other things as well, they should be able to support not only the custom application development, they should support out of the box as many standard applications as possible as many infrastructures as possible.

So it's not only about software development is more, the policies you define should be business centric. So if you have to do pule exactly, I think it's too complex as job support for different types of policy information points. So where are the policies stored? Where do you retreat information you need for conversation? That should be very flexible. Cause you have directories out there. You have different policy stores that has to be flexible. And you have to look always at the, the way applications interface with these things. That should be very flexible.

That should be different options from using maybe exactly directly towards having trust. A simple call where you say, okay, that's my query is Martin K allowed to do that. And then you provided in, in a way, which is adequate to the applications. So there should be different approaches. And the more you have the better it is for what you really need to do. And there should be out of the box integration with things like provisioning directories, because that's one part of your entire infrastructure. It's not the entire infrastructure. It's a part of it. That's also where you should look at it.

So what do we really need? We need few consistent layers for access control. So we need to define points of controls, where we really define these things. It should be strategic and it should be something where we really move forward. Step by step. We don't solve everything quickly. The point is pretty simple. We have a lot of applications out there, which we never will be able to integrate this. So it's sort of a long term tactical thing, but it's also strategic thing. The obvious thing is you have done a standard approach.

You use, you use one lead firm and you do your authorizations against plus what you need to support sometimes other types of applications. But the, the core message messages think about external of security and especially of entitlement management or ization management today start strategy and then really start doing it because every application you don't manage locally anymore is really a big win for you. With having said this, I will hand over to super develop making the presenter and he will then talk about real world use cases for externalizing, hetero genius environments.

So it's your term, Look into the, the server. We're going to discuss overview of Oracle entitlement server and how it relates to solving real world use cases. This is a standard Oracle disclaimer. And during this presentation will be talking about some integrations that that might need additional customer work. This is the standard question that, that everyone asks.

Why, why, why do I need find the entitlements, right. I think Martin has done excellent job. So I'm going to skip this light. One of the interesting aspect that we see when, when talk to customers is a lot of them hate the fact that their security policy and app are fused together. We tend to see that application features are driven more by, by where the business, what the business wants to do, what, what the envision in the future, but a security policies tend to be driven more by vulnerabilities that are found by security researchers or, or hackers or something like that.

So you almost have no control over when you might, you might end up with a new security requirement, whereas you tend to drive application requirements. The nice thing externalizing your entitlements is you can spread them into two different cycles and, and drive each other separately.

This is, this slide talks about the overview of OES it's just to get started. So that way we'll have an idea when we are actually discussing use cases.

It'll, it'll give us a better context as to what the use cases and how customers are trying to solve the problem. So, and, and I think this is fairly standard for, for all entitle service. You have users sending requests and your authorization server receives that request.

It, it ranks through authorization policies. It, it arrives at a decision and it gives a final grant or that that's typically how most, most authorization service work. The nice thing about OES is we have lot of, out of the box custom integrations with, with java.net, other environments. And also we can directly access information from external repository, like at that database web services slide. So these are some key features of Oracle enter server. One is centralized policy management.

Martin Martin has already gone, gone over some of the benefits and we see pretty much a hundred percent of the customers moving towards centralized policy management. One, one of the main issues they have is they tend to move track of where security security policies are located, where they enforce, or the structure is. And over different provisions of applications, they, it becomes OUS.

So the, so you have to focus on central and centrally managing your, your policy, especially security policies. And OS has rich policy model.

We, we support vac our back and, and a whole bunch of other standards out of the box. And the, the nice thing about external security is some of the overhead that goes into actually changing your application or modifying your API. You're going to immediately receive benefits because your policy model will, will be simple compared to what you previously had in code. We also have out the box integrations with Java, Java ecosystem and dotnet, and, and so as well, we have, we focus on deployment flexibility. Lot of times customers tend to overlook deployment options.

What we find is generally app application developers don't focus on deployment. So we, we see customers starting taking up a project and, and almost post to completion. That's when they decide, Hey, how do I actually deploy it?

How, how can I use this? Right.

So, nice thing about OES is your application development cycle and your deployment cycle are, are detached. So you really don't have to care about how it's going to deploy later on.

And we, we have some of the best performance and scalability we, for, for a typical deployment, we see customers, we, we, we see that OES gets around 50 authorization requests per webpage. So that, that kind shows, shows how much that kinda shows how important performances you really have to scale up because from end user perspective, which is one page, but in the back end, you're making 50 calls and, and scaling is just as important because as your deployment goes, you have to make sure that you, you don't take a performance here. All OS deployments are in, in 24, 7 environments.

And we, we make sure that we, that whenever, whenever we release a product, we, we don't have any single point failures, any new feature and all that to go, go through and standard support. We, Oracle server supports RVAC AVAC and, and lot of other, other emerging standards as well. Our goal is to be where the industry. So we don't want to force our customers into an aback mindset or our back mindset or any, any, or force them to marry a particular standard. Rather they they're free to choose what they want, and we'll be there OES we've.

We've had customers that, that have OES and deployment for, for over 10 years. And they're happy customers.

And, and there's a lot that you learn over time when you, as your product begins to mature, because initially it's all about mitigative features and mitigative things. But over time, you, you tend to focus on what it really takes to keep them in production, make sure that they don't have an outage and Oracle enter server as a sense support.

In, in the Java ecosystem. We have lot of out box integrations. We support that services RMI. One of the things that we often find, find with customers is they, they start out with a single application or, or single J to server, but overtime, they start ING on lot of the, sometimes it's out of their control because it comes in as part of an acquisition. And sometimes it's a pointing solution, right? So very soon customers realize that they, they they're, they pretty much lost control.

It's, it's one thing to have the management overhead of, of, of maintaining multiple ecosystems. It's another kind of a problem. If your security, if you lost control over security policy. So the nice thing about OES is even though your application deployment might be fragmented across different technologies, your security policies can, can be essentially managed and we support our unified API. So this API hides all the, all the underlying differences.

So it doesn't matter whether you're running in say web logic or webpa or, or JSE, we we'll make sure, or even in Toca, we make sure that your application will work exactly the same. And the API will, will keep the transparency for you. Porwal we, we see lot of customers user use with Porwal as well.

So the, there are subtle different within Porwal versus J server. And Porwal we have that structure, right? For example, in web logic, you have books pages S right there, there is a structure, and there are some semantics around how structure, how content is placed ES out the box supports integrations with, with lot of different. Porwal so nice. So the nice thing is OS understands what, what kind of a structure that you will have in the future, right? So you start off with a small application, build a little bit, and then you, you keep, you keep adding on top of that.

So, nice thing is O OES knows how we are going to go, right? So we let you directly map your S your webpages and all, all, all kind of different objects back to OES policies and managing privacy is, is, is getting more important. As we see what's happening on the internet, you can map your privacy policy. You can map your privacy statement to an OES policy.

So even if there is a dev team, or even if there is a developer, that's, that's actually some code, which is leaking your information, your security policy will automatically make sure that whatever application you develop, doesn't violate your corporate policy, Content management, some look at content management as, as J on steroids or your applications or on steroids. But, but we really think it's different. That's because content management is, is a vertical solution that that's designed exclusively for documents And, and multimedia and other kind, other kind of information.

And there is, there is a lot of rich information. The say, for example, if you're word doc, right word, doc, has the author, other attributes, any, any security privileges that that are required for, for viewing or modifying the doc and all this kind things. There's a lot of rich meta information that's present along with each object. So OES understands, OES understands this meta information and, and, and lets you use those artifacts as part of writing your policy. So for example, you can write a policy saying the person is allowed to view this document.

Only, only if he or she's present physically in, in their office. Right. And another interesting side of this is content management companies tend to be more, more volatile in terms of their licensing.

For, for example, if you look at satellite or cable TV, they keep sending out this new offers every every two months, right? So the licensing model change changes every two months and they need to manage which person is allowed to view which content, right? So if that is hard quoted, it becomes a nightmare because you have to change your app every two months, rather they externalize it to, to authorization engine like all years.

So, so anytime they have a new licensing model, you just go modify your policies and, and, and you're done. Oracle entitlements is, has, has very good integrations in the so ecosystem. We work with lot of vendors to make sure that we, we have all we, we WeWork seamless.

So the, the interesting thing here is lot of our customers like to drop OES plugins into these example, you can take OES and just drop it as a plugin into Porwal and your world automatically start. Afor your funding authorization policies for, for all, for all services that are provided by the gateway. And we also integrate with article server shoot and, and then, and web services M with services manager.

We, we see a lot of interest in using OES with service bus, because the nice thing is service versus sort of centrality or deployment. And you, once you tie that with OES, you have a certain guaranteed level of service, security, and production. And one of the nice things here is that there are almost no code changes required. We have out of the box integration with a lot of solar products. So for example, if you're using OS with water gateway, right, we, you don't have to make any code changes. It'll just work out the box. Data security is, is an interesting problem.

And, and it's, it's probably a little more complex than all the other things we talked about earlier. So here, so some customers like to think about security as only in terms of data. So they have a data center view, right? So if you have a, if you have an application, a GSP or something that that's rendering content and you keep looking at, okay, where is, where is it getting the data from? Right. Ultimately everything ends up at the database. So database is the origin of your data.

And they, they view securing that information in the databases as, as the most strategic option. And another way to look at data security is following the data, right? So the data is born in the database, that's where it's originates, but where it keeps sticking through your network, your solar deployment, whatever. And ultimately it, it ends up in, on a customer stream, or it, it ends up with your partner for some ordering information or something like that. Right? So it's important to, to make sure that your security follows the data, right.

Just because you have point solution doesn't mean that it's, it's all done. So one application might be secure, but there could be something else that's leaking your information, right? Annoyingly. So with OS, a nice part is because we have enter integrations. You can have OES deployed everywhere in your network, wherever. So you can have OS deployed anywhere. You think you have strategic data, right?

That way a central, you can define all policies centrally and make sure that the same set of policies are, are governing the data flow all the way from where it starts in the database and where it ends on a, on a user screen. And lot of customers use out of, out of the box integration with SQL. So you can, you can use an, you can use an SQL filter to redact data redact queries.

So if a person runs a query saying, Hey, show me the S for all the people in the company, you can add, you can add a filter on top of it and make sure that it says, show me salary for all the people who working in the company who report to me, right? So that'll automatically filter, filter the data and, and make sure that you don't have any privacy issues.

We, we also have, have a VP integration, virtual private database integration. This is where you can drop an OES Oracle intelligence server module into the database, right? And then the next thing here is all your applications will automatically get wired. So even say, if you have some obscure application that, that, that cannot use authorization API, then you can drop OS module into the database. And as these app applications are, are trying to access data, the, it automatically do the enforcement for you.

But one thing you have to understand is when you're working database, the information is, is, is draw compared to when you're working in higher level applications. Because in applications, you have a lot of other meta information that, that you can make use of, but this is an option that a lot of customers, like one of the problems that we've seen with, with these kind of deployments over time is that there is a fair amount of concern about adding, adding external dropping external plugins into database.

Generally DBS tend to be fairly paranoid, so they don't want any external plugins being dropped into database because Oracle loans, both database and, and the best product in the market. I think we are strategically positioned to come up with a really good solution. And I think the right way to do that is to actually build a fine enter solution within the database. So database out of the box comes with a fine enter solution, and the solution can put your central central administration console.

So you're still defining all the policy centrally using one console and your database will just become managed when, when it comes to security, we are, we are seeing customers deploy, deploy OES for, for cloud based applications. It's is just speaking up right now, but there's a lot of interest. Lot of customers want to see how, how OES and fine authorization can fit into cloud deployments.

The, the main issues we see are around data. So in, in pretty much all, all deployment models, you, you have very little control.

You don't, you don't own where your data decides you own the data, but you don't own where the data data decides. So the question becomes, how, how do you know which applications are accessing, right? What are some arbitrary app application accidentally accesses your, your, your schema, right? And how do you know that that users are getting authorized correctly before they're presented a piece of information?

So you, you have two tiers. Every application has to authenticate before it gets the data, and you have to authorize users as well. And one of the options we have say, if you are, if you are working with extremely important confidential information, like in us, the social security members or your passport members, or something like that, you can actually encrypt them.

And, and then just rely on OES to use that information, to process that information. So should someone accidentally back up your schema, you are passport numbers and everything would still be encrypted, which is, which is a little better than, than what it would be otherwise. So right now, we, we are seeing three different, three different deployment models for cloud. One is clouds, infrastructure versus platform versus software.

I think all of them share the same underlying pro problems in the sense that you really have to worry about your data, how your data is moving and who gets to see what, how you, what authorize applications, I think as, as you go down. So infrastructure, you have more flexibility with platform. You have less.

And, and if you're using the pure SaaS model, you have the least amount of control. And the concern also in increases in the same order, if the infrastructure you have more control, it's easier to secure with SaaS. You have absolutely no control.

All, all you can do is sign a contract, right? But I think what we have to, I think the industry is moving is to provide some kind of guarantees, right? Just signing a piece of paper. Doesn't matter. What we really want to know is how a SA can, can prove to us that they're not leaking that information, right.

We have, we, we, we already have seen O going into development with, with multitenancy multitenancy is an interesting idea because it, you have a single application that can potentially service competing customers, right? The, the way we and our customers see that identity management is a foundation for market tenancy.

So, so essentially if you try to build multitenancy on your own as an application, it's very complex. The goal is to use ID management as a foundation, and then, then sort of build on top of it, authorization standards, like I mentioned earlier, or our goal is to support every authorization standard that that's used in industry. And we don't want to force customers into a partner say, you have to support this XYZ standard, right? We support our back.

We, we support, we support vac and, and also we support claims based authorization, which, which Microsoft is, is pushing very hard there. This is sort of a birthday view. It just shows you what you come up with when you, when you search on Google, I, I won't go into these numbers, but, but it sort of shows you where the current state of effort are.

Our, our back is, is obviously the most mature. We are seeing more adoption and planes in AVAC exac is, is clearly emerging standard. So when you are one of the important things with, with deploying the solution is, is enter and integration. You have to make sure that your T management fits it works, works as a team, right? You don't want authorization that does something on its own authentication that does something on its own provisioning. So because, because Oracle owns IBM stack, we, we very much have product that, that cover authentication, authorization, provisioning another.

We put a lot of effort to make sure that the, these different competence I operate. And Occasionally we see all this kind of nasty box, right? So for example, you can, you, if you're using one authenticator with another authorization, in theory, it should work. But in practice, we see a lot of issues with bugs and these kind of things.

And, and also just the fact that every, before every release, we actually go through regressions and make sure that everything just fits into one, one large piece. OES is a strategic for Oracle. Pretty much every product in Oracle is, is going to be built on top of OS authorization agent. This means any, any new application, any new development, anything that's done is going to rely on OS authorization. And we are also working with lot of companies that have been recently acquired to see if they can replace an authorization engine with OES as well.

I think I've gone over a few crossed my thing, this, this a summary of what we've we talked about. Oracle intelligence server is strategic for, for Oracle. And we have a huge customer base that, that, that that's growing that's rapidly growing.

And we, we are very flexible. Oracle intelligence server is very flexible and it supports a lot of platforms, databases and providing models. So I think we are open for questions. Okay. Yes. Thank you for your presentation. And I will go back to showing my screen. So we have several questions out there and I'll start going through them. So the first question we have the Oracle entitlement server and implementation of the exec reference processing model as published in the standard. So what does it implement from the standard Martin? Let me take that question.

Yes, please. Yeah. Oracle has been a very active part spent in that second standard standard. We have the, we have, we have the co-chair actually the co-chair sit sits right, right. Across my office. So we've been very active approximate in INAC and OS policy model as aligns with the SAC standard.

So it has, it has the same kind of attribute based access control model and, and, and all these kind of things. We, we support request response.

So you, you can, so if you have in trouble use case, you, you can send exact request and we can talk to them, send responses and moving forward. Right. We are waiting for three. So what's the really want to do is, is as, as these pieces are measuring, we are going to interrupt. We don't want to jump the gun and say, Hey, let us pick up a standard before it's approved. Because then again, if there are some changes, you run into all these issues where you are breaking compatibility for customers in production.

So what we prefer to do is wait for pieces to make sure and, and then, and then incorporate them in the product that being said exactly strategic for all years. And we, we are going, we are going support standards as, as they get approved. Okay. Next question.

I have, we have a lot of questions, so, so we should focus on, on, let's say, focused answers for these questions. Can you describe the.net? And so are integration of OES in more detail?

So Yeah, so we, we have excellent. So integrations, we have integrations both with products that sales, as well as our partners say with gateway.

And we, we have a lot of customers that have just integrated over, used to work with say data power. Right. And my understanding is that these integrations are very straightforward. Okay. Yeah. Go ahead. Yeah. Oracle authorization. So the authorization of different products is going to depend on OES when, and which versions of these products will then support do OES. I think that's probably, you can't say that much about us, but maybe you have some information up at least about some of the products which will then rely on support wees.

Yeah, absolutely. So as you know, Oracle is a big company, so we cannot come up with a manager saying next to this, everyone has to, has to rely on OES. Rather we are working with individual teams.

So within, within our T management, Oracle access manager already uses OS Oracle T manager already uses OES. And we are, we are working with lot of different teams. There are several products that are in the pipeline that are going to pick up OES in the very next release.

I, I, I cannot talk about them in advance, but if you're interested in specific use case, do let us know. But, but we already integrate a lot of, including the logic Porwal and, and whole bunch of other like PPM, OSB and other products. Okay. Question I can answer quickly is the presentation available for offline mode? Yes. The presentations of both presenters will be available by tomorrow at our website for download. So another question, if we have so many, and if you can't go through all the questions, we, we might just answer some of the questions in my blog.

So we will then ensure that we answer them offline in the block. I think very interesting question. What is the largest number of rules managed by OES in real world deployment?

So far, We, we have seen customers that, that have over 60,000 policies. And one thing you have to remember is for OES authorization engine, the number of policies is, is not that big of an issue, right? It's more of a management problem. So imagine if you had 30,000 objects in your house, right. And try finding one of them, it's going to be a nightmare. So general recommendation to customers is when you're designing policy, try to see how we can structure the policy to represent your business. And OS has a lot of artifacts.

We have virtual resources inheritance and all these kind of concepts to, to really help you simplify the policy modeling that being said, this particular customer that I just mentioned, they had a legacy system and they, they had, we work with them and double play tool to automatically migrate their existing policies into OS. So that, that's why they've ended up with such large number of policies. But our recommendation is perhaps have fewer number of policies and come up with the clean design. That way our system will be more manageable. Okay.

Another question or say there, lot of large number of questions, what do you do in OOA as when the it landscape changes frequently? So do you need to update the rules? Are they dependent on, on the systems or how do you manage, for example, changes in the it landscapes of things, move to another server and system and so on.

So we, we have, you have a couple of options. One is just go and modify these, these information.

Say, for example, your database, all of a sudden change from Oracle, say DB two to Oracle, right? You you've been using DB two database. Now you won't move to Oracle database. We have standard procedures for all these. And the nice thing is we make sure that every procedure can, can be automated. And our recommendation to customers says, you try these procedures in, in your development cycle or QA cycle.

And, and in production always do them in an automated way. Okay. In addition to the presentations, they are available for download right now. So if you look at our website and to two events include that webinar, then you will find the presentations for download another question, how many simultaneous authorization requests we support in its largest installation right now? So we have, we have seen customers normally run at least 500 simultaneous clients as, as part of their QA. It's hard for us to judge exactly what kind of load they get bigger.

Obviously they, they, they don't share that information, but we see them running. This is pretty standard almost, I'd say 40% of the customers that we see.

They, they run loads around 400 to 500 concurrent users. And as far as scalability of OS goes, then I think OS scales with your application. So whatever policy application that we do is, is done in the application context on application threat. So as your application scales, that your application is hundred threats. So OS itself doesn't impose any scalability restrictions.

So, so maybe you could describe some, some, one or two of your largest deployment styles of, so, so for example, are, are there the, the banks or other institutions, finance industry series finance industry, which have a very large number of applications working against OES for the sourcing request. So maybe one are two examples of that. I think that would be very helpful to, to, to give the audience and an impression of how this works in practice.

Yeah, sure. So one of our, one of our oldest customers' been in production for over a decade right now they have accumulated more than 300 applications that, that are more yes. So what we see is sort of a variation applications that are customer facing tend to have large number of users, right?

So for, for example, we, we had, we recently had a customer that, that went live where they're using OES to secure, to protect customer information. So think about this as, as sort of like a social website. I wouldn't say social network, but, but social website where, where people log in and then look up information about others and trends and stuff. So the nice thing is they there's, this website is by OES. And I think there, their customer base is probably in, in millions if, if I correctly.

So it's, it's a very, it's a very large deployment, I mean, huge number of customers. And they use OES as a, as the engine to, to, to, to make sure that their privacy policy are, are not, are not breached. That that's one example.

There, there are other things where say there are some deployments where OES is used just by a small team. So they have something that's very, that's very important that has to be protected, right. And have a whole bunch of regulations, how, how it should be done.

So in, in those cases, the policy model is very complex, but, but your number of are probably in hundreds. So you have a variation in this use cases. And I think part of it depends on the deployment.

If you're, if you have a customer facing app, you you're better off at simple set of policies, don't make your policies too complex, right? Make it simple. You have large number of users, your applications on a scale. But if you have something important that that say only vice presidents in the company can share or something like that, then you have a complex set of policies around it and more control. Okay. So I think we are close to the top of the hours.

So we have several questions left, but some of these questions are pretty complex and I think they're better to, to answer offline and we will publish the answers then. So let me thank you at point of time, all the attendees and super for doing his presentation and hope to see you soon at the repeat, nonconference a good place to meet by way also place to meet in person then to have appointments with me and the I Analyst as well as different sponsors like Oracle, have a nice day, have a nice evening, depending on the times on you. Thank you again. Super. Thank you again.