Good afternoon, ladies and Charlton gentlemen, welcome to our webinar dynamic externalized also for the evolution of the service-oriented architecture, using AAC for APIs and microservices. This webinar is supported by AIOS. The speakers today are cherry Gable, who is vice president of business development at Matics Americas. And me Martin I'm founder and principle Analyst at a coal before we start some general information about a coal and some housekeeping information. And then we'll directly dive into the topic where we talk then about attributes based access controls for application programming interfaces for microservices. So for the modern world of application development, many organizations are already using independent international Analyst company. We were founded back in 2004 and we focus on information security and it was in there. We have a strong focus again on identity and access management and governance, but we also look at other areas such as the church transformation and many others.
We support our customers with our research, such as our leadership compass documents, our executive use, and other types of documents with our events and with our advisory services. When looking at the events, we have a series of upcoming events. So late November we'll do our consumer identity, went in Paris. We will then do one in mid-December in Singapore. We will do an event focusing on the regulation tax or the rec tech space, which also goes then to it ERC and many other areas, which we run in December early December in Germany, in Frankfurt. And then we have the digital finance world again, late February next year, and our flagship event at the European identity cloud conference, which will be, will be run next year, May 15th to 18th in Munich. So many upcoming events. Plus a lot of new webinars have a look at our event website.
We also, as I've said, provide advisory, our used addition to that is our GDPR readiness assessment with which which helps organizations to understand whether they are ready to meet the requirements of the upcoming EU general data protection regulation, which will become effective next year. End of may. So this is a very efficient, very streamlined approach to analyze the readiness of organizations for that specific regulation, some guidelines for the webinar before I start. So you are muted centrally. So we, you don't have try and mute yourself. We are controlling these features. We are recording the webinar and we will publish the podcast recording as well as we will publish the slide X latest by tomorrow. And that will be a Q and a session at the end. I always recommend that you enter your questions once you have them. So that we end up with a long list of questions and have a lively Q and a session at the end of our webinar.
The, the agenda has always is split into three parts. In the first part, I will talk about new challenges emerging from service oriented architects and microservices in particular, but also take a little bit of broader view on why do we need externalized services? Why do we need a service oriented sort of security architecture as well? And I also will touch the point of how to make WEP approaches. So this minimal, minimal viable product approaches secure. And the second part then cherry Gable will talk about or demonstrated benefits and potential issues of deploying authorization as a microservice. He will elaborate in addressing those challenges with the help of additional conventions and standards. So he will go really into detail. So I'll sort of set the stage for him with the broader frame for why do we need to do that? And why do we in particularly do it also for microservices world and cherry then will really look at more details down to, so I would say close to inflammation, patient details.
The third part, then we do a Q and a session as I've already said. And instead I directly move to my first slide. So what we still see far too much as software development, where security is not used as a service, but where security is built in that piece of software, which is developed so built in, so to speak coded security, what I've indicated with the wide rectangles and, and this picture, whereas the other, the red ones are for externalized security, sort of as a service in the sense of there's a service consume, which might run on premises or in the cloud. But as I've said today, there's still a lot of build and coded securities organizations create a piece of software either because they want to sell it or because they needed internally or because they do it for a customer and everything, which is around security is done by themselves.
And so what it, what it means in consequences, that there are several impacts of that practice, which are critical when you do coded security frequently upon us, security comes as an after third, it's considered being a pain in the development. It seems to only cost time and money. It's challenges the time of delivery, the time to market. But if you look at it, realistically, my perspective is that many things are, are in reality, fairly different. So if we look at the reusability of code and of other, particularly of the security parts of the code, obviously if you use it as a service, we are on the good side. If we build it in a certain application, we are on the bad side. So we don't end up with reusability the effort and cost of coding. So the overall coding is obviously more positive. So more to the right side in that picture when we use it as a service, because we reuse security features, we use them as a service instead of coding them for the application.
So less effort for coding if we do it right also. And I think that's a very important point skill level for coding is lower. The more we rely on services and creating security in your own code, doing it right, is a tremendous task. It's not easy to do it. Good. We all know. So your risk also goes down the flexibility for changes. So if you rely on a well set, well sort outside of services, your flexibility for changes is obviously higher because you rely on the services on the interfaces. The time of, and cost of changes is better. And it's far easier to do. Security audits is extremely hard to do code and security audits. When you use built in coded security, when it's only about tracking which types of services are used, things are far simpler. So from that perspective, and we could elaborate far more on that.
There's a good logic in saying, we look, we, we move to using security as a service. We have our services, which provides the security features we need, and that could be a variety of services directory. So not creating one user management and user store per application obviously is a good thing to do. Relying on centralized directories, which are centrally administered, where you rely also on whatever standard interfaces for self registration and all that other stuff makes perfectly sense. Authentication, authentication as a service means you also can move to adaptive authentication to flexible approaches here, authorization. That will be our big topic today.
If you code authorization into your applications, it's literally impossible to really do a code review and audit security audit of these applications. You end up with hard coded business roles, rules in many scenarios, it's far better, far easier, and far more effective to use authorization as a service, and then start a new concept. I always say, you know, when we look at the mainframe environment, 90, 76, IBM released the first version of RF, which basically was about externalization of authorization and externalization of security. So it's not a new concept, but it's a concept we still don't use frequently enough audit using centralized audit feature, centralized audit locks, reporting, etc. Why should you build your own reporting capability? If you can rely on standard audit and reporting tools, encryption, user self-service privacy, which becomes more and more important. So when you look at the requirements of the upcoming GDPR, then using certain minimization becomes something which is highly important and all these can be security services, the basic model, them isn't that very high level.
At that point that we say we have applications or services, which then in fact, either through standards. So standard protocols, we have such as LD up or O OS two or whatever through specific APIs. So APIs that are exposed by certain infrastructure service or through an API layer, we create to have a sort of common layer in our own software, software architecture and through preconfigured modules and services. That might be also part of that approach, which are then consumed by these applications and services. So we have one layer here and so everything, a adapted layer. So these applications and services are isolated from what is loaded layer. So the directory might change. As long as the standard still provides access to the information, the same way it always has been. Then the application doesn't need to be changed so we can leave applications untouched while we, for instance, runaway extend whatever our infrastructure below, where we add new features.
If we do that entire thing ride, which also then reduces the friction we frequently have between the people who are responsible in the organization for either software development or for the applications around the applications, cetera, and the infrastructure, people who have to provide the other components. And so there's a lot of launching in saying we move to that model, this approach also that you trust rewriting on a report. I wrote back in 2007. So which is about application security infrastructure. So this topic is one which is under discussion for more than 10 years right now, how should these infrastructures look like? And it's something we definitely need to do when we look a little bit more into the details of that. So let's look at a little bit more detailed sample from practice. So there are applications, there's an identity and security services layer and there a platform services.
And so the access to the security and services layer in that case might go through certain modules which are provided and deliver certain preconfigured functionality. For instance, the user registration set of registration. If you're building a series of Porwal for your customers, you might rely on one embedded module, which provides features such as the password reset, the or service, the user registration and others that might be preconfigured modules. You embed here. Then you might use certain APIs or you might use standard protocols to access the underlying services. So with standard protocols, you might go directly them to the platform services, which are provided by certain backend infrastructure service. While for other things, you then sort of form one layer of rest APIs. You might even have an API rep, the API rep then sort of translates sort of your standard set of APIs to the, in quotas proprietary APIs of the backend infrastructure services.
And based on that, you can create an architecture, which is, which is really based on standards and your own sort of redefined API layer. And with that, you isolate as that before you isolate the applications and the way they consume security from the underlying infrastructure services. So it's providing a consistent set of services and moving to security as a service you use in all your applications. So the developer does not need to care anymore about how do I do the encryption in detail. He trust uses the service. He doesn't need to think about how do I do the authentication in detail. He relies on the service and the service then can provide the adequate authentication methods that makes software development far more efficient, far more straightforward, far more secure. And when we look at this from and service oriented architecture and microservices for which are from a conceptual perspective, not really very much different.
Then at the end, we move to an approach which combines the orchestration of an application. So with the various services we use for the application, so the microservices, or when you go use sort of traditional sewer approaches, the, the, the services we consume in that orchestration and we have security services, which are orchestrated as well. So it's not different than any business service we usual or application service. The security service is also something we use here. However, they obviously are some challenges arising in that area. So first we need to accept yes, security needs to be implemented as a service. So first we need to, to really accept, yes, this is something which is just part of the overall concept of good, well sort out microservices or software oriented architecture approach, also security as a service, not only the business services or application services, but also security we need to bridge.
And this is from my experience in that entire communication, the biggest challenge we need to bridge the gap between software developers, software architects, security, architects, and security infrastructure. So there are people who run that infrastructure and they have their, their target and saying, okay, I want to have a consistent approach for my directories. I want to have one authentication layer, one authentication tool, etcetera, the security architects frequently come in with very high requirements on what they need in security. The software architects need to understand that concept and the developers finally need to really use it. And from my perspective, it's important to make it very simple for developers. Developer will use that if it makes their life easier. So if it's a simple API call, yes. If they have to learn a lot and do a lot and to fill some complex coding, they will be at least reluctant.
We look need to look at performance and scalability, a topic. I'm sure Jerry will touch on his part of the presentation, the entire implementation of the security services. So the security microservice, which then goes out maybe to a backend service that needs to be very lean. So it must be a microservice and the microservices itself clearly must be secure. But my perspective is the only way to do it right, is to move in that direction. And it also will help us to make better. And we pee journeys, so to speak. So we, we hear a lot of talk about WEPS the minimum viable products these days, but an WEP only is good if it's something which can mature. So if it's something which works as a proof, but then needs to be rearchitected to mature, then we did something wrong. And if we do it based on security services, the logical journey as we start, we test and we extend because our security is a service and mechanic temp, the entire thing without detecting security.
If we fail in doing it that way, if we just build in security and ANP approach, then we are very likely to take longer because coding security takes longer than consuming services. We test and we fail to extend because we then identify that the security is not good enough for what we need. And then we start rebuilding it. Eltron is far longer. I might have oversimplified here, but basically this is the point behind it. Even while sometimes the argument is that the fir that it's easier to, for the first time to sort of build in security at the end, it doesn't pay off. It's always more expensive and it over time always takes longer. So move to security as service I'm convinced and VP approaches and Microsoft microservice architectures will in inevitably fail without well sought out security services. How these well sought out security services could look like that something cherry will right now talk about cherry L make you the moderator, and then it's your term.
Thank you very much, Martin. So that's a great introduction. I'll, I'll definitely expand on some of those comments that you made and, and talk further about externalizing authorization for, for APIs and microservices. And I, I often use APIs and microservices interchangeably, although I recognize, you know, the, the differences there. So please bear with me on that note. So for, for those of you who are not familiar with Matics, we do, we are a security software company that specializes in access control or dynamic authorization solutions. And we we've done many other webinars and have a lot of other content on AAC that is attribute based access control. And, and today we're gonna talk about how we apply AVAC to, to APIs and microservices, but we're not gonna talk about the basics of AVAC today. So we'll assume that you have some knowledge there and also for today's content.
I, I want to give a shout out to some of my colleagues who we've been having a, a lot of interesting internal debates and discussions about this topic and, and the, the content you'll see today is the latest iteration of, of our thinking on this. So a shout out to Matt Carter, Jonas SBA, and MOS, Hokinson, who, who are on our customer relations team. And when we talk about security and access control for, for APIs, what we see is that in general customers use our solutions to define those policies or rules for how you grant or deny access to various kinds of resources, be they, the application itself, APIs data, and what have you. And today we're talking about the API channel because that's one of, actually one of the primary channels that we use to enforce these kind of rules, whether it's to enforce privacy, such as GDPR, other regulatory issues or business or security rules that the organization needs to enforce.
And we think that when you build out your security infrastructure or architecture for securing APIs, I think as Martin, you said, it, it really needs to be based on, you know, the, the use case, the scenarios that are being implemented, the sensitivity of the data that needs to be protected. And we can actually use multiple standards to implement these kinds of requirements, because we think there's, there's some complimentary capabilities that an AAC approach provides here. So why, why do we have so much interest in, in APIs and microservices? Well, I think a driving factor here, a driving force is the, the whole digital transformation era that we are in now. It's certainly one of the, the biggest buzzwords that you see thrown about in the industry, but it's a significant trend that we have to be aware of from an identity and security perspective. So digital transformation, it's all about being customer centric, providing the very best user experience, whether that's for your customers, partners, even your employees, we're not forgetting about them.
And what I'd like to think about here is that we're removing barriers to access, removing the friction from getting to the data, to the information we need to do our jobs more efficiently, more effectively. And there's also a business reason here, right? There's so many businesses that want to become digital, be become more modern. And this is also induced by a number of different factors, whether it's competition within your particular industry, of course, new entrance to your industry. We've seen so many disruptors in, in many different markets these days. So that overall market dynamics keep keep changing. And of course, customer demands keep evolving as well. So there's a lot of factors from the business side of the house that are, you know, focusing our interest on APIs and microservices. And within it, this means that your developer teams are building applications. Now, as microservices accessed via APIs, we, we see this over and over again, it's, it's such a common trend, either new applications, new customer portals being built in this fashion, or in many cases of existing applications, being refactored, modernized, and rebuilt and deployed as a microservice style application.
And then on the management side, we, we hear a lot about DevOps, the development operations. So this is the team, the operational team that are using different kinds of tools now to orchestrate and manage these applications and what they describe as a continuous integration or continuous deployment approach. So this means they want to rapidly be able to implement changes on a almost continuous basis. Maybe not quite to that extreme, but absolutely more frequently than we used to in the past. So this is the mode of operation. And I, I think here, even we've heard from customers that their focus on high availability is actually overriding the, you know, the historic or traditional notion of, of individual component reliability. So that's sort of an interesting development maybe to talk about more as well. And then as, as Martin said, we really need to think about security services, identity management services in the same mode.
You know, how, how can you best fit into a DevOps model if that's how applications are being built and deployed. Now, we also need to think about doing the same with our security services. Absolutely agree with that. Now, I'm not sure if, if everyone's familiar with a wasp, the open web application security project, they, they are a great organization that puts out a lot of terrific information about developing secure applications and they, they publish this top 10 list and it's been pretty stable for a while. You know, these are the top 10, most common security issues that are found in applications tier. They made a couple changes here. So you see on the right a four, they combined a couple of from the previous list, a, a four and a seven, and then they introduce a new, a 10 at the bottom. So under protected APIs has reached a level of concern with, with, and it's now on their top 10 list.
So definitely another reason to be concerned and focused on this topic. And so when, when we look at how applications are built, as I said earlier, you know, as a microservice, you know, the different functions, and then you can at least theoretically make composite applications by combining these functions as Martin alluded to. What about security? Where is that in this model? Often it's, it's left off to, you know, a future phase or we'll, we'll just try to hard code it in, into the APIs themselves, or some of the common patterns that we see are the use of ol two oh models. You know, for example, open ID connect to secure microservices. And in many cases, this could be fine, but the concern may arise when you're handling more sensitive information, whether it's privacy, data, health information, intellectual property, and so on. And this is where we think that aback and the exact standard can add some, some capabilities that are, that are complimentary.
But the key is, I think also as Martin pointed out, is that when you develop your architecture for security, that it should be capable of handling a wide range of requirements. You know, not just the simple cases, but can you adapt to both course level access control, but also fund grain access control requirements. Can you deal with handling, you know, data that's, you know, more public or, or lower classified data, as well as the sensitive data that we're talking about here. And also, can you address the needs of any user constituency, you know, or any, any kind of access channel to that data through the microservice? So these are things to be thinking about when building out your security architecture and when within the OWA 2.0 model, we have this notion of scopes, you know, so scopes are, are, you know, designed as a way for a resource owner to delegate some kind of action or consent to a client application.
And this is a discretionary access control model, but it feels a lot like our back or a role based access control model. So we, we can make, you know, some, some comparisons to that model, for example, our back for a web application, a user logs in to some identity provider, they have roles maybe mapped to groups in LD a or, or role definitions in LD D. And so when we log in, we get that information in the session and the application can check if we're in the admin role in this example. So then we need to ask, you know, our scopes, the new R back this, this data flow is absolutely very similar instead of an IDP. You have an OAuth authorization server, that's stored scope information about the user, and they get those scopes issued in, in some kind of token, maybe a jot token, for example, and then that's passed along to the microservice request.
And now we're checking if you have the scope admin, so looks pretty similar, but it raises the same concerns. And, but in this case, you know, is scope explosion gonna happen similar to how we've seen role explosion in, in so many deployments. And then also there is a potential for something called API bloat where developers actually have to create separate APIs perhaps to serve those different communities that I, of users that I was talking about earlier. You know, so one API for customers to make requests for access to data, separate ones for partners, employees, and so on, or even in combination for that, we can hard code those access to policy within how do governance over that kind scenario, how do you do audits and cert certification of access, and, and this also results in more time consuming and costly maintenance as we change APIs in the future.
And then furthermore, there's also this, this idea of, of, you know, tight coupling model within the can, can present some issues. I wanted to point out here that also that typically an API gateway of some sort is, is an intermediary here acting as a resource server. So that's essentially act acting as a policy enforcement point. And you can see in this example where, you know, the, the client is issued a token from the author O authorization server, that token is forwarded to the gateway who does the evaluation, whether that request should be allowed or not. But when you have personally identifiable information involved, you know, that's something that maybe the OAuth model isn't quite well equipped to handle. So we think this is an opportunity for that API gateway to call out to an aback service, again, acting as the policy enforcement point. And the aback service is the policy decision point down here at the bottom, which has those centrally managed and defined policies for, for access to in this case, PII data, it has access, or it has the capability to consume and evaluate a lot more attribute and metadata information that the OAuth model doesn't necessarily have awareness of.
So there's, there's a lot of more richness that can be implemented in the policy decision process if you externalize in this particular manner. And we'll, we'll also talk about some other scenarios, but even in, in the current diagram here, the business service itself could act as a policy enforcement point and call out to a PDP. So there's a number of different deployment patterns that are possible here. So why do we do this? I mean, this is not different from other reasons for externalizing authorization, you know, data is, is the commodity that we want to be able to share, but with the right organization, with the right communities, because we wanna monetize, or we want to U utilize that data APIs are now the most common way to, to share this data. But of course we want to limit who gets access to what data at what time and in what context, so what about, can we filter data through these API calls?
And we can make an authorization decision on the initial data request? You know, I'm trying to do a get record for record number 1, 2, 3. I can present my token and it's validated, and yes, I can request that data, but there's a potential for data leakage here. If sensitive data is returned and, and not handled properly. So an interesting concept here is that we can actually do authorization on the return of the data to the calling client. So this is what I was talking about earlier, being able to examine and act on all the richness of the metadata available. So we can look to see that the region in this case is EU and therefore on the way back to the client, we can redact certain fields. According to policy, again, with the, the API gateway calling to the AVAC service to determine which fields should be redacted.
So this is a little more detail of how that looks again, the API gateway acting as the policy enforcement point, calling out to the authorization service. And this is where we, we set up those rules and policies in order to, to, you know, implement that authorization on the return, back to the client, not just on the original API request, very powerful capability to implement this. And then just to take another, a slight detour here in talking about scope grants, there's actually a way that the authorization server in OAuth can call out to the aback system to validate whether certain scopes should be assigned to a user or a client. So that's another angle where the, you know, the aback system can integrate with the OAuth model to, to implement fine green access more on the token issuance side of the equation. But also the microservice itself can, can call out directly to the authorization service of this time of the AVAC system to validate at time of access are all of these scopes still valid for this user.
And they can also evaluate that access request based on the other, the other context of that particular request at that particular time, because possibly there's, there's stale data within that token. So what about this, this last question here, can the, the policy decision service be modeled as a microservice and should it be done this way? Well, we think the answer is yes, because when you think about the PDP module, the policy decision point module itself, it's a stateless module and it's immutable. It has in the exact most standard, a well defined interface. That is the request format of an access request message and the response message. Furthermore, these are defined to, to be restful and encoded in the JSON format. In addition to XML, there's a bounded context for, for accessing this service and it can be deployed in a fault tolerant mode. So yes, we think the PDP service, the policy decision service can be just another hexagon in of, of a microservice in your architecture and see here from the original diagram, we've added the open ID connect microservice at risk based and analytics service, even an OAuth author authorization server. So these can all interplay and compliment each other to give you a more comprehensive authorization service for APIs and microservice architected applications.
So to summarize some of these comments and move on to a discussion of your questions with, with Martin, we think we, we agree with the notion that the, the service model should be adapted to your security services as well. So the, in the OAuth structure, the resource server and policy enforcement server here should be separate as we, as we discussed. And we can treat things like the policy decision service as a microservice and deploy it in such a fashion. And we have several customers that do that already today. You put it in a container, manage it as a microservice in that fashion and utilize scopes for what they were properly intended for. Typically that's delegated consent, and we can enhance the, you know, the, the security of microservices by externalizing the policy decision from them, reduce the API bloats, or reduce the scope creep. And we think there's a lot of benefits in going this fashion. So we've got quite a bit of additional material on our, our plug in our technical blog on this topic. And I think Martin, we can now open up for questions from the audience.
Thank you, cherry. And let me take the control back. So we already have a couple of questions here, and as I said, please enter your questions using the questions feature in the go to webinar control panel. So one of the questions that came in was what is Matics view on Uma? So the user managed access standard.
Yeah. Excellent. So Uma does allow for different policy models and policy engines within its definition. We've been, we've been tracking its, its progress for some time here and, and have it on our roadmap to, you know, to come up with an integration when we, we have the, you know, the user customer demand for that. But I think, you know, Uma is, is a great profile of the, the OAuth 2.0 model. And like, and like I said, you know, there's, there's definitely a role for, for AAC and, and axiomatic to play in there.
Okay. Then one of the other questions is please explain more on the statement you made regarding higher availability versus reliability. I think that's one of the trade-offs we always looking at trust earlier is they had another conversation about scalability and performance versus security. So we have to accept trade. So maybe you go more detail around ha where there's reliability,
Right? Well, this, this notion of, of high availability and, and the focus on it is sort of caught me by surprise over time. You know, I, I used to work at, at a large bank in central it way back in the day, and we are absolutely focused on reliability. You know, that was, seemed to be the number one metric that everyone was concerned about. But with, with cloud computing models, people are, are using, or the, the cloud with the cloud model, people are almost expecting that certain services will fail, you know, because the, the reliability of the cloud infrastructure isn't a hundred percent or even five nine. So the way they compensate for that is they will just spin up, you know, more servers services than they need. And if one fails because they're stateless, they just, you know, fail over to the next ready one. So it's interesting how DevOps teams are, are approaching the, the high availability equation in, in a cloud model. So they, they are looking now to have a pool of services available rather than making the, you know, the one or two services. Absolutely rock solid and, and as reliable as possible. I don't know if you've seen the same thing, Martin, but that's in, you know, development based on my history. That's just feels kind of strange, but it it's logical at the same time.
Yeah. I, I think that it's logical and I think it's probably in reality, it's the easier way to do it. So
Yeah. Easier and more cost effective, I think
At the end. Yes. So another question, your, okay, go ahead.
Yeah. Sorry. And, but to your, your point about performance in scale, excuse me, I think with, with performance, I think with scale, we, we address that by just making more services available and you can scale up quite easily that way, but with performance, I think as usual, you have to look at the, the deployment architecture, you know, where are the resources that you are protecting, where they deployed, where are, where are the attributes metadata sources deployed? Where is the decision surface itself deployed? Excuse me, sorry. So, so similar, similar to on premise deployments, we always need to look at where those components are because that's where the potential latency can be found. And then we can address, you know, the performance concerns and, you know, typically find a way to deal with that.
Okay. I've got a couple of other questions here. Can Abe be used for at least some element in achieving GDPR and PCI compliance?
Oh, absolutely. I think within the, with GDPR in particular having the, you know, the consent model is, is a very important aspect. Right, right. Having the, the consent metadata available. So we don't manage that consent profile information, but we would be a consumer of it. And, and it's quite to derive the implement or enforce those consent preferences. So absolutely AAC has a, has a role to play in and in enforcing GDPR requirements. And we see a fair amount of interest in, in doing so. And what was the other one that you said
PCI compliance was the other one.
Yeah. PCI, not really as much. I think most organizations with PCI data have already used other mechanisms to address those requirements. I think in many cases it's tokenization of data or encryption of data, but certainly there's, there's ways that we can, we can compliment, you know, those, those functions, those capabilities with, with AAC as well if needed.
Okay. So another question I have here is how is your authorization service deployed as a microservice?
Yeah. Typically in that container of some sort, I, I mentioned Docker on one of the slides. It seems to be the, probably the most common way to do so today. So yeah, the PDP module can, can be simply deployed within a Docker container. And then you, you can deploy that container wherever you, you wish to, you can manage those containers by, you know, using an orchestration tool like Kubernetes. We're also working to, to examine how we can also manage the, the policy updates through those kinds of tools, but, but deploying the PDP module itself, quite straightforward to do that in a, in a Docker container. And then, and as I was saying during my session, you know, this makes the deployment of the authorization service, very similar to how you're deploying your applications. So I think there's a lot of value in doing it in that manner.
Okay. Could you, could you also talk a little bit more about best practices for authorization as a microservice for deploying as microservice? I think you touched it, but I got it here as another question. So maybe you could dive a little, little bit, little bit more into detail here.
Well, I think it actually links back to some of the comments that you made Martin in really planning for the proper architecture upfront. I was had a conversation with, with the new customer just the other day where they said they added authorization in phase two of the project. And they had been working for more than a year on, on phase one. And it actually took quite a lot of rework to now add in the security that they needed. So it absolutely mirrored your, your extended timeline there where they didn't quite rebuild everything, but they had to do a lot of reengineering at, at that phase. I think, you know, in, in like any other security or identity project, you know, the upfront planning is, is so crucial. And, and I would say second to that part of that planning would be to look beyond those initial simple use cases that you're implementing and, and try to look out, you know, two to three years, what are the more complex things that you're going to attempt? Because you know, many of these microservice application deployments to these digital deployments are, you know, early stages. So they don't have full functionality in the first release or two, for example. So I think making sure that you're accommodating what you expect down the road is, is gonna be very beneficial.
Yeah. And I think what, what I've observed following for long term is there's, there's common argument. Oh, it will cost us too much. It will take us long to set up such an service architecture. I think reality is with what we have and the experience which is available in the market. I think the only situation where it comes challenging with respect to the time for deliveries, when you're already in the middle of a development project and you, then you experience, you did it wrong, but when you do it from the scratch, even of a single project, it will be more efficient to work with the service approach. And that's even more true when you do it in a strategic and saying, okay, I know that I will have a lot of development projects as part of my digital transformation over the next years, I spend some time and money to, to create this service layer. It'll make everything far faster and more efficient. So I'm absolutely convinced that it's the better way. And, but the most important challenge from my perspective, different best practice perspective is communicate the right way with the various people and, and really show them the benefits that this makes everyone's life easier. So the win-win situation, which can be, be a consequence of it.
I agree with that. And that goes back to the planning process and having the right stakeholder representatives in, in those discussions. And, and then you do, you, you do have a better chance of coming to that good resolution.
So at the final question I have here, that's question where you can either answer very short or very long is how long does it take to implement AAC?
Well, yeah, it can be very short or very long. A lot of that depends on the readiness of, of the organization, the, the planning that they have done already so far, we've seen an implementation happen as fast as a three to four months. Sometimes they, they do take longer, but I like to categorize the, the effort into a few major categories. So one is, you know, documenting what are the business or security rules in natural language that need to be enforced. So that's part of the, you know, the, the policy modeling exercise from that you derive your data model. You know, these are all the attribute definitions that I need to know about users or about the resources. So that's, and, and then you can map that to the sources of those of that attribute data. And then you have the, you know, the integration phase, you know, how are we going to integrate with the, the resources?
Is it going to be through an API gateway through database proxy? You know, some, some custom JSON coding, and then finally the deployment design and architecture, the deployment configuration to address high availability, performance scale, and, and so on. So I think those are the sort of the four major categories of effort and organization's preparation and readiness really impact how quickly that can happen. But we see, you know, organizations can get value in as little as, you know, a few months. And, but, you know, a lot of this just does depend on the normal, the cadence of deployment of technology at, at the organizations, you know, so some might take six months or longer to do so.
Okay, perfect. So thank you very much. I think we comes for all the questions we had received. Thank you very much to the attendees for listening to call webinar, hope to have you back in one of the upcoming webinars or one of our events we do over next couple of months. Thank you, cherry for the in-depth information you provided.
Thank you as well, Martin. Enjoy doing the webinars with you. Thank you very much, everyone.
