Externalize Authorization - XACML and Beyond

Good afternoon, ladies and gentlemen, this is Martin Ko of Cole. Welcome to our Cola webinar, externalize authorization exec and beyond webinar in which we will talk about the need to, to externalize standardized authorization and using exec Mo using other approaches, doing it not only for custom applications, but also for standard applications. And so on this webinar is will, will have two percenters, which is me, me, and which will be then do Stan of PKU. And this webinar is supported by PKU. Before we start, I'm shortly an information around copy. ACOP a call is an Analyst company.

We are providing enterprise it research advisory, service support, and networking for it professionals through our subscription services, where you can access our research through our advisory services themselves in all of the areas we are covering. So cloud security, identity, externalization authorization, so making concepts and that type of things and sorority events and our main event, the European identity conference, which is co-located with cloud 2011 conference. Those will be held in May 10th to 13th of May and Munich.

You can still provide nominations of interesting projects for the European identity awards, which are given way there every year. You'll find some expon sponsorship opportunities at our conference website. And for sure you can register now and get your early bird count, which is well until I think March 15th. So it's time, time to ladies and gentlemen. Good afternoon. My name is yore. Sorry. We have some I'm back here. Okay. Okay. Okay. Sorry. It looks like we have honestly looks like we have a technical problem with the software we're using, which usually is very stable, but things happen.

Obviously I trust dropped off the line. Hopefully it doesn't happen again. So I will continue here. Okay. Okay. Some guidelines for the webinar. First of all, you will be muted centrally. And so Dr. Muted centrally, so you don't have to control the mute R mute features. We will record the webinar and we will provide a recording usually by the day after the webinar. So if it should be there tomorrow and Q and a will be at the end, you can ask questions using the Q a tool to effort, to area questions and your go to webinar control panel.

You can ask questions at any time, we'll pick them at the end or if appropriate, although we might pick some questions during the webinar. So that's what we'll do there. And right now let's directly start with the webinar itself. So the agenda, like I've said, we have two speakers today. Like in most of our webinars, the first part will be done by me, Martin Kuppinger. I will talk a little bit about externalization for authorization, the status and trends.

And the second part then will be done by Stein of, he will talk about how to gain access control for all of your applications, from SharePoint to the ones you're building internally. And then we will do our Q a session, like I said before. So our topic today is externalization security, art of applications. And what does it mean?

It means really that we have, that we look at how can we do all these things around security outside, you know, that hard coding, not having a user management per application, not managing authorizations and our business rules per application, but really looking at how can we do an external use of management, which is pretty common. We frequently use external directory. So that's very well established. And how about external authentication? There's some things are going forward.

So we have to sum things and we have, for example, active directory, which is used for a lot of applications to indicate external logging and auditing is not that popular these days, not yet. And external authorization would mean we have comprehensive set of policies, things way level centrally, and that's I think what, what we, what, what we should look at. So externalizing security out of applications. And I'll talk about reasons about what is going on the market and things that there are some good reasons why we should do this. One of the reasons is we should avoid hard code is security.

If I look at today's typical applications, a lot of security is hard code and especially a lot of business rules are hard coded. So you have constraints for, for making authorizations within your application logic frequently, and that's very hard to change and, and doing these things externally is much better. You can do it for all applications. So manage across, across all the, the different single applications, but centrally, and you really make changes much easier. And externalization, I think, is relevant for a lot of different reasons.

So one is software audit in many areas are a legal requirement. So you have a lot of areas where you have to do the software audit requirement. It's about matching risks. So business processes are at the core of your risks and managing authorizations.

In fact, per webinar, per managing authorizations per application is a, a task which not really leads to situation where I really know what are my business rules implemented here, there, and so on. So do I really have to correct business rules implemented you don't, you're not audible table in that area. So that's really a problem you have. And in fact, it's about meeting compliance requirements. So it's about control, access, sensitive data by different processes, reuse of services. It's about also the, of costs of software development. So avoiding unnecessary costs as part of governance.

From my perspective, that's very important. If you look at typical application development today, people are, are really developing their security. There are authorization rules, again and again, per application that's cost incentive intensive, and it's not leading to very good results. And so if you'd like to have secure business processes, not only business for, we have to get the externalization of security out of applications into a standardized layering into central management. And it's also very interesting. One of the servers we've done is around so security.

And if we look at the, the risks and the shortcomings, and so the very high things are down here than higher medium green, then it's very obvious that security risks here at the right pillar and the lack of security concepts at the left pillar are amongst the most critical things when it comes to so as security. So from that perspective is also very important to, to understand that we have to do something in the area of security. So we have to consider, and that's what I recommend we have to consider doing external station.

So the conclusion from that perspective is there has to be so a governance as something where we look at risk management, security efficiencies, re reuse, audit, and accounting, and especially security and reuse of security and the related things like risk management, the ability to audit things are things which can only be met when we are looking at the topic of externalization of security.

So what are the business drivers for this one business driver definitely is at tri so having applications where we have our business logic outside and where we don't have hard coded security, in fact means we are much more at trial. We can change business rules on the flight. If you look at, let's say Barry, very, a agile industry like telecommunications, like utilities there, you need to be able to do that on the fly, not by changing applications of having tests and all the other things to your life cycle and using, or taking months and months to really bring these things into production.

So that's really where it comes to the area of compliance. It's really about compliance. How can we do it from that perspective? How can we stay compliant? And it's about cost cost. I've talked about this before, in the sense of how can we reduce cost of application development by reusing security, by not reinventing the time. And so doing externalization is as part of, let's say the, the evolution identity and access management. So sometime ago we mainly had individual island where we had an application, its own users, which is its own identity management.

And that case, especially provisioning helped us to provide changes for about users to all these applications. So we have the provisioning tool in the middle and we exchange this information, the next luxury status to, to really have these users once to use, for example, Sam and Federation standards to work with central user based, really not having the users in the application anymore. And the logical evolution data to also put these policies at the middle. So policies not only, so not only the uses the who, but also the, what are they allowed to do.

And that's where we really are looking at during this webinar. So externalizing security. And in that case, especially also externalizing the authorization part to a central there. That means we have applications which are using an application infrastructure and like we are using business services and entrance below this. And that's what let's say core of. So as we are reusing services, you should reuse access and identity services. I explicitly used access and identity services.

Why, why did I choose access and identity instead of identity and access? Cause I think that access that's the real thing we have to solve. Our problem is our main problem is always access who is allowed to do what and to do what, that's the point we need the who so the identity, but our problem is if someone has illegal access, if someone's fraudulent access, that's our real problem to access. And we have the entrance below this provision Federation authentication authorization, policy management at different stores for policy and identities.

And like we are used to use web services today in our application also should for, for the business part, for the business services, we should get used to use access services from an application perspective. These application have to work with standardized services. So the interface, the interface with the underlying infrastructure, we need therefore defined service interfaces. We have some Sam and the web service standards we have exec, which is increasingly mature.

And we, we are decoupling applications and the identity and security and for a world of cloud services, identity and security have to be services themselves. So it's for our internal service. And if you look at a cloud even more, and that's really where we have to move forward, because if you think about a cloud, it's very obvious. If you have a lot of distributed services, you need to manage things, identity security, the access centrally, which role does exact in there. Exactly.

That's so called extensible access control market language standard for separating policy management and authorization decisions from the authorization enforcement. So we are separating the different parts. We can have central policies, we can enforce them dis in a distributed way, in different types of applications and everything is based on a standard. We have several elements just in there. I won't go into the technical details of exactly. We had a lot of webinars around exactly before. And I'm sure daughter also talk a little bit about exec later on.

However, we have an enforcement point where the policies in fact are enforced. The, we have the decision point where the decisions are made. We have an administration point and we need some other elements within this to retrieve the information or policy information points or policy forreal points. We don't have to dive into the details.

In fact, it's about how can we build a distributed infrastructure where we have a central management of policy, but a distributed enforcement of policies in different types of applications and standard. That means interoperability at least to some degree. And I think things are increasing limit resource are moving forward there. And that's our exactly sort of our common denominator is what we really have as, as, as a common understanding that helps us.

However, I think there's, there are some things we, we have to, to look at. First of all, we have to, in some areas to, to, to shield the user, to protect the user from exac.

So, so it's not about having the application developer in, in the usual situations using exac it's having the application developer using simple authorization requests where it says, okay, I need a authorization for this user to do that, that function in the business. He likes to, to do a purchase order, which is $510,000 or Euro. And we have to check whether is a lot or not, or whether is a lot to use the brand that could be done more technical could be something like this. It's not about having the entire segmenting thing there. The other thing is, so it's a very technical standard.

And the other thing is sometimes it's really about doing ever exec. So it's a little bit about how can we make things easy, but really build on the, the advantage segment as providing and from our perspective. So in this, this introductory problem, and D will dive into deeper into some of the parts later on, it's closer, I think, important to go beyond.

So, so if you look at this entire thing, I started with the Sowa this service oriented architecture thing, but it's in fact it's going well beyond it, for sure. We need interfaces applications where we can go out of the application, say, okay, we, we need an authorization done here. And we like to have it based on a central policy. See it's about doing it based on, so on Gateless, especially there where you have applications ready, which don't support it directly. We have to do it in SharePoint related tools because there, it becomes really interesting. How can we really secure SharePoint?

SharePoint security is one of the big piece team. I also say, if you have an application out there and there are dozens, or maybe even hundreds of security tools available for such a tool in a very short period of time that you obviously have a, a security issue there and managing SharePoint security is one of the things, how can you externalize this? How can you also use the same policies, the same business policies to protect the information within share product? How can you use it maybe in the future for file systems security for all of the cost applications?

So the standard applications you have there for your databases and whatever is out there. So my perspective is we need a single set of policies, not only for the applications we build in house we needed for all types of applications, for SharePoint and beyond for everything which is out there and durable. Talk more, more in detail about some of these tools later on, because I think there's a lot of things going on for sure not to forget this. We also will need for cloud services. That's also a very, very important thing. If you look at them, I've talked about it a little before.

If you look at cloud services, we definitely definitely need to also support these cloud services. That's a really very, very important thing because when we look at cloud services, we, we might be able to, to manage our SharePoint security or some of our, our standard applications relatively good internally. But if you're honest doing that for all the cloud services, increasing number of cloud services, that's virtually impossible to do.

So if you look at the market, which offerings to look at, when we, when we talk about externalization, it's like with every, let's say emerging market segment, we have a lot of different names for the same type of offering. So we have some policy service out there and that, but that's be careful that every policy server really does this authorization externalization thing. We have entitlement management, usually all the servers, which claim they are, entitlement servers are in the segment. We have fine trained authorization systems.

We have some few provisioning systems with somewhat limited capabilities, but which let's say more from a historical perspective, also support such things. So we have some vendors out there which have specific connectors, which allow to, to bring in authorization requests. And finally, we have some web service security systems, which also usually have somewhat limited capabilities because they're usually focused really on the web service security part, but there are different types of products, which are in fact doing the same.

So when looking at these things, which are from our, from our perspective, important criteria for choosing vendors, one is maturity and scalability of the solution. And I explicitly state, it's not the size of the vendor. It's the maturity and scalability of the solution. How long are they in the market? Was the solution. Are they able to scale, have their proven, scalability, all that type of things.

And that doesn't necessarily something which is only delivered by large vendors, but some of the, the, let's say the, the inventors of this topic, which came from different angles definitely have proven maturity and scalability because they're doing that for pretty long time. Right now we have to have support for exactly. And I also think we have to support for things beyond excite so that you don't need to use exactly necessarily that you can interface with what is out there. You need support for more than custom application development.

So support for SharePoint support for a lot of other things, building this towards a broader set of systems that might. So when you're start different areas, some are more focused on interfacing with network security over six, with others are looking more at standard applications.

However, I think the tendency is clearly to, let's say to, to branch out and to support more types of systems to really move forward towards a centralized layer. And we need business-centric policies, not Tru support for different policy information point.

So we, when we do an authorization decision, we'll need information about the user for whom this decision is requested. We need to look up in different directory databases.

And so, so we need to be flexible there. And finally, we have to have a way where it's not about log in within the application development.

So, so when you have to build in a lot of lines of code, which are very specific to a, to a single application, then you have to risk of login. You have to change your applications. Once you change your entitlement system. And you always should find a way where you can easily change the entitlement system without affecting the code. You have an application that might be, it might be whatever. I think there are a lot of things that we have discussed over summer of our advice for customers in death.

So that's something where you really have to, to spend a lot of, of time and a lot of thoughts to ensure that you're highly flexible in this area. So that's, that's, these are some, some, let's say some general views on the market. And I personally think it's one of the, the most promising and then most quickly emerging market segments. So we really feel that there's a lot, lot of attention. And what I just want to say is exactly is very important.

But when you look at this market, ensure that you cover not only your own applications, but cover a broad set of applications you have out there over time, so that you really look at how can I work with all these different types of applications I have there. Okay. Now that's been my part of the presentation I will hand over to do right now and making percenter and Dorin will talk about how to gain access control for all of your applications from SharePoint to, to once you're building internally. Do it's your term? Thank you.

So I'm the Stein, the CEO of BKU and there is a strange little blue doc on my screen, but the topic that I would like to talk about is, is really what Martin has mentioned, gain access control for all your applications, whether you build them internally, or whether you buy them from a vendor at Biku. We do one thing and we do it extremely well, which is delivered solid security for pretty much any platform. And hopefully I'll be able to demonstrate some of these capabilities.

Security is an overloaded term, and it would be ideal if there was a tool that gives you authentication or authentication obstruction by authentication obstruction. I mean, your application should not care if you're doing SAML, SiteMinder, curbs, L app, whatever your application should be decoupled from authentication.

This is, this is so that when you change your underlying directory, your application doesn't change. If you want to add biometric authentication or two factor authentication, your application is not changed when you need to support single sign on using all standard protocols. Your application should not be changed when you need to do Federation and Federation includes not just federated identity, but also federated authorization. Your application should not change as new standards emerge or existing standards mutate.

It would be ideal if you didn't have to deal with session management delegated administration. And if you had fine grained authorization in your gooey apps, in your mobile apps, in your web apps, web services, all the way down to the database in a consistent fashion, without having to write a single line of code, we'll talk and show some of that to be enterprise scale.

Any system, whether hosted in the cloud or on premises should have strong audit trail, meaning who did what and audit trail is meaningless without reporting on that audit of who did what, who had the access to do what, as of a certain date, in some cases you need to enforce segregation of duty rules.

In some areas you need to enforce information barriers, and you need to have enforcement for various platforms will cover what those platforms are in a few minutes, and you need to control access to not just custom apps, but to ERP systems like SAP or PeopleSoft and CRM systems, collaboration tools like Documentum SharePoint and others and commercial off the shelf apps come in many flavors. They come as web apps, mobile apps, mainframe apps.

And so on, of course you need to protect your custom apps and it doesn't make any sense to reinvent the wheel. We tell people, do you write your own operating system? Do you write your own programming language, your own database, your own communication protocol, like DCP.

You can, it doesn't mean it's cost effective a business or, or a government, their core business isn't reinventing the wheel. So we tell people, stop reinventing the wheel and start using reusable components that make it extremely easy to secure apps. And when I say secure, I refer back to authentication, fine grain authorization, delegation, Federation, single sign on delegated administration. And so on. Now in an ideal world, every type of application should be able to, to plug into some wall and get full security, authentication, authorization, delegation, blah, blah, blah.

But the reality that most enterprises are faced with is that you are faced with many protocols, standards and products that exist in the space and to require developers, architects, auditors, CISOs, to be experts in the intricacies of exact two versus exact three or Sam 11 or Sam two or oof or open ID. And so on is simply not, not feasible. Organizations should not care what the exact Mo looks like or what the Sam looks like. And so on organizations should deal with business rules and leave the underlying plumbing to vendors that specialize in the space.

What Keystone does our product is it takes these protocols. All of them seen here. And you can think of all of these, or you can think of Keystone as the universal adapter of identity and access management. So whether you need to plug your applications to SiteMinder or to SAML or to boroughs or to L up, and whether you need to support exact 2.0 or 3.0, once you Keystone enable your application, you don't really care as we move forward. And there's gonna be exact four.

At some point, your application will be future proofed because you don't have to deal with the low level XML that represents what exact model is. So that is the main benefit. Now what can be protected.

So today, if you have the.net application, whether you write or post windows communication foundation services, WCF, whether you have web apps like asb.net, ASB dot NETC, whether you have silver light, four, even silver light, three, or WPF, or wind forms, type apps, anything to do with.net, you don't have to write any code to secure those apps all the way from the gooey, through the middle tier, all the way down to rows and columns in the databases. The same is true for Java.

If you have JSP apps or server apps or CXF web services or jacks Ws web services, whether you run on WebSphere web logic, JBoss, Don cat, glass fish, net Weaver, regardless of app server, and regardless of underlying operating system, those Java services and Java applications can be protected without having to write any code whatsoever. The same is true for PHP modules, PHP for Ruby, he airline, and in the works, we have RPG and Cobal for those mainframe and legacy system customers.

We also have a Delphi component, a power builder component, a raw C and C plus plus module, as well as support for calm and com plus. So let's say you are writing an application for Azure. Where do you start to secure the app? Where well, we provide to you a template in visual studio that you click file new Azure protected Keystone app, whether it's WPF or asp.net or silver light, or the WCF web service, you simply build your app without regards to security, and you manage the security completely outside of the application. The same is true.

If you do the Google app engine apps, if you write legacy apps for IIS, we have an, I is AE filter. If you write apps or deploy apps for Apache, we have an Apache module. It already talked about Java and services. If you host services on EC tool, and Martin talked about SharePoint in the realm of SharePoint, we have the most sophisticated controls for SharePoint, 2010, as well as SharePoint, 2007.

We created Keystone STS, the security token service that supports all Federation protocols and all Federation profiles, but we go well beyond Federation and give you capabilities within SharePoint, such as controlling any artifact based on its metadata ability to control access to artifacts based on any set of attributes that the user provides any set of environmental attributes. And we have an exclusive technology that allows you to secure rows and columns in SQL server without touching SQL server and without touching the client.

And hopefully I'll have time to, to demonstrate that we pride ourselves in what we call defense in depth. It's not enough to protect the front end or just the, so the web services or, or just just the web services or just the, the JSSP apps or ASP apps. You need to protect the user interface. You need to protect the web services and you need to protect row and columns in the database. And Keystone is a generic platform that takes exact more version three and compiles it down to iHealth intermediary language, which is the, it is equivalent to assembly language.

So we have an optimizing compiler that treats the exact more lingo as, as a language. And it is the fastest implementation that we know of, but it's not enough to have a very robust, scalable, distributed PDP policy decision point. We needed to build policy enforcement points for various scenarios. So if somebody's chatting with me, okay, now, so we covered how we do it. Let me show you an example. I'd like to show a virtual machine I have, and in this virtual machine, I have SQL server 2008. I'm gonna issue a, a query. I execute a query. And in this NASA test database, I have the DBO schema.

I have a table called launch and the launch table has these seven rows. And I can see here, Mars, Pluto, moon, and the launch dates for those launch targets. And I can see whether the launch was approved or not approved and what the access level was. And so on. What do I do when I want to control that certain people should only see approved launches and certain people should not be able to see the launch date.

Historically, I had to go and write either stored procedures or change my query to say, select just the approved columns, maybe ID and launch name and so on from NASA test where approved is equal to one. I could do that, but that would require me to change the front end, where the front end, I may not have access to it. So let's take this generic query, execute it again. And we can see that we have access to everything. What DB wall is before I show DB wall, which is a specific policy enforcement point for Keystone. So I'll first I'll explain the type of P E P that this is exposing.

If we have a database and we have some application using the database, it passes some sort of query. And I'll just write some query here of say, for example, select all from customer, and I'll make it a little bit larger. What happens if I want to restrict what the user here can see? Let's say this user is only allowed to see column three, four, and five, not all columns in the customer table and only customers that are in the state of California.

Well, if we introduce a policy decision point and I'm sorry, policy enforcement point specific for databases, this is what DB wall is. It exposes on the wire, the same protocol that the database exposes. So to the caller, it appears on the network as if it is SQL server.

So now, if, if we call DWA, what will happen is it will fix up the query in two milliseconds and say, select columns, two columns three, and column four from customer where state is equal to California. The database itself doesn't know that there is a row and column level security apparatus that is protecting it because it is in line. And we can change in DNS saying where before the database was IP 1, 2, 3. Now the database is IP one to five, which is DB wall.

We can also isolate the database behind the firewall and expose the database only to this particular host, preventing any other host from reaching the database. So we no longer have to maintain users into database. And we can also control what type of information the user can, can request DML data, manipulation, language, or DDL data definition, language. We can restrict. For example, DBAs to say, they are only allowed to issue DDL data definition, language that create table drop table and some other user to be able to do the ML like select insert update, or delete.

So DWA is a specialized P P that talks to Keystone or other PDPs, and it allows you to accept any sort of query and it logs the IP address of the call. How did they authenticate the original query and the fixed up query? So that's now that we know the architecture, let's go back to the virtual machine, go to the DV wall administration interface, and I'll define a rule for the launch table. So here I can see the servers I have in this virtual machine. I have a database called NASA test. I can show all the schema, I can secure views, tables, store procedures, functions.

I have a table called launch, and I have a rule that I will edit. And I'll say, here, let me show the columns. I'm gonna say where approved is greater than zero. So this will create a restriction on the rows that the user can see. And the user, any user that has access to this particular secured entity will be able to see that only roles that are were approved is greater than zero. So where before I saw approved is one end zero. If I connect again to the same database and run it, you'll notice that I can only see where approved is one I don't.

And there is no way I can circumvent this information. And it doesn't matter what client is calling SQL server, whether it's Microsoft SQL server management studio, or whether it's SQL server reporting services, it makes no difference.

So here, I'm showing you a concrete example of an app that was written some time ago. It has nothing, it doesn't know anything about security, yet it respects, or it has no other way of not respecting because it is calling DWA. It's not calling SQL server. How is DWA employed? We have a windows service called DWA that exposes a port that you can specify or number of ports. And on the network, he talk exactly like SQL server. So that's a type of P P we don't have time to show all of the PPPs, one for net, one for Java, one for SharePoint, one for PHP. And so on.

This is just a concrete example of, of security. We can also secure columns. So let's say where before I saw the launch date. Now you can see it's 1969. And so on.

I can say, let's add the launch date as a restricted column, and I can add additional columns as restricted. I save it. I reconnect to establish a session and I reissue the query. Notice that the launch date, the column is still there. Cause if it wasn't there, it might break the calling application, but the date is the default date and we can override what the default is. So for example, we can, for a string, we can say star star, star, or unavailable or express a regular expression that only shows me the first two characters in the last three characters and so on.

So if you need to, you know, start out a credit card number and things of that nature, you don't have to go in and write code. I know I have about three minutes and then we'll start the Q and a. Is that true? Martin Martin? Yes. Okay.

So, so that's just an example of the policy enforcement point. Let me think what else I wanted to talk about. So to conclude, and we'll open up questions and answers. When you please don't enable an application, you are decoupling yourself from the authentication provider. You can get audit trail of who has, or had access to every individual functions function within the application, and you don't have to write code at all. And our message is clear and simple. Don't reinvent.

The wheel security should be thought of as a reusable component, just like the OS, the database, the communication protocol, the programming language. There is no reason to reinvent the wheel with that. I'm happy to take questions and mark in how we're gonna do this. You're gonna, yeah.

So I, I have to, I have a very big list of questions available, right. Or in front of me right now. And I will read the questions and, and then through me, or are you, depending on the question will, will answer it.

So, so maybe let's start with, with one question which, which I might pick, and you might add on the question is what, what are some examples of authorization policy policies that apply to those SharePoint sites, database records? So there, so are there any real world policies out there which apply to SharePoint sites and database focus? I would say yes. For sure. For example, you might have information marked as PII as a personal identifiable information or so relevant, and you would, you might like to limit the, the availability of this information to a specific person.

So I think it's that very hard to find these things. However, for sure many policies will be relevant only for, for issue systems. But if you go, if you look at, for example, custom developed system, and sometimes also Cox systems, which are dealing with some specific business data might have a lot of exams where there are same business rules applied to a lot of applications.

So yes, for sure. The frequently goes beyond the single system.

Yeah, I'm, I'm, I mean, you've answered it. I think correctly, there are, we see many use cases in, in various domains, in banking, in healthcare, in defense and government, where based on artifact metadata, and based on environmental attributes and attributes provided by certificates that users present as well as external Sam request and external LDAP request and other types of attribute retrievals, people can gain access. I'll give you one concrete example.

It has to do with defense suppose the government has, or government agency has documents that, that are usually classified like blueprints or buildings and maps of critical infrastructure. And they typically do not want to let people that are not within the certain department gain access, but in case we have a national security event, like God forbid nine 11 or something like that, they would like to have first responders such as policemen, the national guard, or, or firemen have access to those critical documents.

They can mark those documents as, as such with some additional metadata and let the entitlements management system reach out to some environmental database to find out whether we are in code read or not. And if we are people that present certain attributes, gain access to those artifacts, that's one out of, you know, unlimited number of scenarios. That's one that we've come across and we've implemented. Okay. I think we, we moved to the next question.

As I said, we have a very long list of questions and I'd like to pick as many as possible. So in case that we, we aren't able to, to answer all the questions was in the hour we have. So until the top of the hour, we will answer the them afterwards in my blog. So I will and send them to, to do, and then I will provide results questions as part of my, of my blog there. So one of the questions, which I think is very, very interesting here is how does this all scale if, if I have many applications with dynamic interactions, so where does the policy come from? Who maintains it?

How can I get confidence? The rules match with my requirements, and that could be 10 thousands of rules. So how do you deal with the scalability issues with the, let's say the match of a rule with the requirements and how to maintain a larger number of rules? Sure. So the scalability is something that, that we've implemented. I think in a, in a very elegant way, we have a policy persistence point that takes rules, versions them and stores them serializes them into a database. And the database is replicated over unlimited number of node.

So you might have one database in Munich, one in New York, one in LA, and you can have, we have one customer with 36 instances around the globe that would support, I would say, billions of users and billions of rules. But so, so that's for the policy itself in terms of the policy decision points and the policy enforcement points. As I've mentioned, we take the exact policy, compile it. We make an assembly out of it, and it is available for retrieval by authenticated and authorized policy decision points.

The policy decision point calls a policy resistance point and finds out what has changed since the last time it called it and that new, or just the Delta or, or the change comes down to the policy decision point. The policy decision point then holds the policy in memory. And the policy enforcement points themselves are mini PDPs, or they can be mini PDPs. They are configurable. So you can distribute the applicable policy to individual PS.

The, when they issue a request, they get a subset of policies that, that offer a match. And so the policy isn't served from one central location. It is stored in, in, in one logical location, but it is distributed across many nodes, but it is a fully distributed system.

So it is, you know, the, the scalability is completely unlimited. We tested Keystone with 180 million simulated users, and we got a subsecond response time on a couple of H P DL, five 80 systems. We have customers with millions of users, performance and scalability is, is fantastic and never an issue. And if you wanna see concrete examples or, or do a deeper dive, just send me a note, the wrong@bco.com, happy to provide answers. Okay. Just the Keystone PDP execute all of exec or subset.

No, we, we provide support for all OFAC mode. We actually provide a full exact mode, three engine. So we support all of the exact mode, three specification, and we have written a very performance transform engine that can take exact two request and then translated on the fly to Exacto three. That is what actually gets executed by our engine. And then on the way out, our context handler takes the exactor three response and translates it to exact more two. So we support the full, the full specification of Exacto 100%. Yeah. Another question, thank you for presentation.

My questions directed at functional testing as an important part of any software development process, inserting an intermediate layer like DBB that is governed by the business side, makes the Hercule task as a number of test scenarios, increase exp financially, but you, your advice to resolve this issue. So, so maybe I started with the answer. I think you, you, you, the, the, this ion raises an interesting point because overall, if you look at, at say ity, we are very well used to deal with, let's say, aesthetic structures for, for access for our authorization management.

However, once we have more flexible business rules, things become more dynamic and then rules are independently try. And I think that, that the understanding how these interact and how does it mean, what does it mean for an application? Definitely. It's a very interesting and very complex task. So what is from your experience with your customers? The answer on this question?

Well, in terms of testing, including a, a declarative security layer, whether it is on web service invocations, whether it's on the EY or whether it's down to the row and column level security, I think externalizing the decisions makes testing more robust and more accurate because you can create automated unit tests that can go, and rather than change code, the unit test itself can call the policy administration point web service, make policy changes, and then test against those policy changes to make sure that you get the expected result.

All of the administrative functions are available as soap or rest based web services. So let's say using the rest, what we've observed is people have written unit testing harnesses, where they invoke our rest based web service to change policy and then create assertions or assert whether the expected result is there or not. Also in our tool, we have a debugger that allows you to do what if scenarios, you can provide a set of attributes, run them against a, a certain version or the rule, see what you get as a result, you can do it either graphically, or you can do it programmatically.

So I think it increases the robustness in terms of testability. Of course, you still have to perform tests, but not having to write custom code gives you more predictability and, and more robustness in my mind. Okay.

Another, I think very, very interesting question for a cos app that has its own authorization, local store, where how, and probably if, if possible at all, can you blaze a P P or PDP to manage authorization? So, so how can you interface with cos applications you'd like to do yeah. You guys out there. Yeah. So that is the most common questions we get. And here is my answer. We have four ways to integrate with a, with applications. We have the pool model, which I typically demonstrate, which I haven't today, where you embed some policy enforcement point in the application.

If you don't have source code, or you cannot touch the source code, obviously that's not an option. There is a sub option where if the application is a co app and it is deployed as a JSSP app or ASB app or Apache app, or any type of web app, like I, we have intercepts that at least can control the UI or the HDML rendering if it's a web based app.

And, and you have, the host is fully protected. You can add additional controls at the UI rendering piece. And of course, if you DWA, you can secure it down to the database. As we saw, you don't have to change any sort of client or server, you know, logic. So that's one way to do it. Another way to do it is we expose and we expose an LD app interface. So if the legacy app knows how to consume LD app and relies on L D groups, we can expose dynamic attribute, driven roles that map to, to L D groups. That's another option. The other option is the push option, which is we can use an SPM L output.

We let Z Mo take user attributes. We have the Keystone snapshot service that goes and correlates and finds out what are all the things the user is entitled to do. And we can take that and spit it out as SPM L. And if the target application has an S BML adapter, or we might build, or a partner might build an S BML adapter, we can write into that application's data store. If the app does not publish what it's data store is, maybe it's encrypted, obfuscated unavailable, and you don't have source code, then you're out of luck. So it is not a server bullet.

It is not, you know, magical. There needs to be some sort of interface capability. What we advocate is don't just go and Keystone enable all your applications, just because if you write new apps, then it's a no brainer. Do it. If those apps don't pass security audits like surveys or, or PCI, maybe look at, at incorporating Keystone at, as a proxy or retrofit the app. So it is a loaded question, and maybe it'll take more time and maybe I need to write a blog about it and, and give a more detailed answer. Okay. I think we are also running out of time, right?

So like we've said, we will take all questions. I will forward them to, to go and will provide an answer to me and I will take them and, and put them into my blog sometimes comes from our side as well. Thank you for all, for the attention for attending this webinar for all the questions.

Yet, as I said, we'll have a recording available soon, and presentations of will also be available as a PDF version. So, and time a look at our other webinars, there will be a lot of other webinars within the next few weeks. And for sure, don't forget to attend European identity conference, because we will have several panels around this, where we can really deep dive into what you have been asking.

And we will also have several webinars out there with, so usually including B Q, and I think it's very good opportunity then to talk with and directly into drill on into the details then thank you and have a nice day. Thank you very much. Bye.