#Keycloak DevDay 2024: Flexible Access Management w/ Keycloak & OPA (Thomas Darimont, codecentric)

thank you much okay good morning everyone my talk um and [Music] or so and away and yeah I was nominated to be first off and few aw from the world and yeah make for you all and hope we time give a again to the organiz EV and thank you very much forting up this event and putting up this awesome together to do that and yeah all things fun start uming auth Au very and authentication about we want we want to us it's very and every day authorization like we determine what to do and here we to see what res toess control are support Cas very well look at kind of control what user can user can users are not which user can group or which the authorization services that klooks provides the authorization service on the other hand are a complete within K itself um that enables you to that enables us to write flexible Access Control policies yeah um there are a lot of built-in components built-in rules um that we can use we can also use JavaScript to customize it or we can even write custom uh policy enforcers of rules uh so to speak via the SPI that's provided um and so so on although if that what keylo provides to you is not enough you can of course always write your own custom extensions like Custom authenticators Custom required actions to do certain access checks and so on yeah uh by the way uh you can you have some uh configurability in klug already also if you use the JavaScript support that KL provides um where you can have basically without writing your own extension in Java you can also uh do things like restrict access to certain clients with JavaScript yeah and uh of course there are some uh community extens available that helps you uh in that regard like if you want to restrict access to a certain client you can use the restrict client out um extension Community extension provided by or built by S to over there um that is really flexible and gives you already almost for for 80% of the use cases everything you need yeah yeah so and what are the supported Access Control mechanisms that we have in klog well of course we have this classical role-based Access Control model um where we can check whether a user has a certain role or whether it being a client role or Ram role and so on or um we can leverage a attributes based Access Control where we can check for concrete attribute on a user like allow access only for users that have an attribute code plan with the value premium and so on we can also limit access uh with authorization services for instance to particular users directly like only allow users like Alex cindia and bird to access certain applications we also have some support for context based Access Control uh where we can say Okay access is only allowed to a certain resource during work week from 9 to 5 or we can restrict access to only be allowed from a certain Network and so on yeah um and this all can then be combined uh by using by leveraging a feature called policy based control where we basically can create aggregate rules based or aggregate policies based on those building blocks above that enables us to write complex rules um that can be applied in all sorts of different contexts and even if that is not enough uh what what you have here you can extend your own mechanisms uh via the SPI so before I show you uh how an alternative could look like we first have to look at U some uh basic infrastructure for policy based Access Control mechanisms or components and here I have a small example um of an application um where a user wants to access data uh certain data in the application and um every access or every data request go goes through a component which is called a p a p is a so-called policy enforcement point which is basically a component that inter intercepts requests and creates some kind of an access query for that yeah um the access query basically contains uh usually the identity the operation that the user wants to perform and the resource the target of the uh operation all this uh is then sent to another component called a PDP which is a policy decision point which is effectively a component that contains some logic in the form of policies like a set of rules maybe um that uh is responsible for deciding based upon the data from the in Access query request and maybe some additional data uh whether an access should be allowed or not uh these policies are usually managed through a policy Administration Point like a component that uh yeah manages policies like has some kind of versioning concept and so on around it maybe and so on uh that uh can provide policy data to the policy decision point and sometimes the policy decision Point cannot work on its own maybe the data from the request and from the policy is just not enough maybe it needs some retrieve some additional data information from other sources and for that we have the policy information point that gives us basically in stuff like additional role mappings Ro hierarchy information permission to role mappings or other organizational information yeah um all this information combined the policy decision Point can eventually make the access decision and return an access response or policy response uh back to the policy enforcement Point whose responsibility it is now to uh yeah enforce that decision like to allow or deny the request yeah and uh that's basically what you find in every application more or less that has some sort of authorization in place sometimes it's uh it's all in one component or distributed system components whatever but these building blocks you can usually always identifying the system somewhere yeah like when Spring Security um uh you have this components in place uh even if they are not named that way but they are actually uh working with that responsibility so how does that look in KL uh the simplified diagram so here for instance a user wants to access a resource uh from through an admin KL admin endpoints and something something like that and and KL especially if you use the fine grain uh permissions uh the endpoints effectively serve as the P the policy enforcement Point that's where it's basically um checked enforced and the access query is basically that performed against the authorization Services which acts as the PDP in keyo and all the other stuff uh like the the policies that are defined are then provided through the real management infrastructure which serves as the policy Administration point and on the other hand we have the r model which then serves as the policy information Point like the data you work on to decide upon whether access is allowed or not yeah that's what we basically have currently however uh I don't know uh everyone who has worked with the authorization Services already knows that it's not all uh um all shiny and rainbows there yeah because there are some severe limitations for instance you can only use the authorization services or at least currently for confidential clients so if you want to restrict access to public clients or something like that it's currently not so easy because uh you cannot enable it on those clients um also you have to use it in some use cases like if you want to use fine grained admin permissions as I said you need to configure all sorts of infrastructure with the authorization Services there which is not fun especially in larger environments also if you want to use Advanced o features like o token exchange also you need to create a a client policy that enables that token exchange um and just in order to to to enable this smart functionality you have to deal with another subsystem again yeah yeah also as I said there is currently no built-in support for restricting access to a client you can create policies that Define that that restrict access to certain client applications but you cannot enforce it in kyl at the moment yeah um directly and uh that's why where you need either custom extensions or to use Community extensions or the JavaScript support for instance yeah and in practice I've learned in in uh over 200 customer projects over the last 5 years it's quite difficult to use actually and very hard to maintain if you have a large uh policy base uh a large infrastructure that you need to cover and uh yeah also it's difficult to manage via configuration as code tools right because it uses its own and points to manage uh the configuration and uh yeah you need to um you have a configuration as code tooling that supports those those endpoints um which uh not every two can and if that is the case you uh need to Resort or fall back to your own script based uh policy update mechanisms and so on yeah so to me it seems that at at least at the moment authorization is currently not treated as a first class citizen in KL at the moment and I'd like to change that and I hope you agree that this is a good idea um let's see how can could an alternative or an enhancement at least to authorization Services look like um let's recap or let's just Define some requirements so what what do we want or what what what would be nice it would be nice if we could Define policies just via code no UI clicker involved we could just write code that can be easily checked and verified we want to easily validate and test our policies maybe potentially even without touching Klo yeah um we also want to be able to change policies easily and maybe apply a gitops like approach because we Tre can treat it as code we can deploy uh a giops like process to to roll out new policies uh that gets then applied automatically over time also we want to be able to trace and follow policy decisions to see why a certain uh access request was denied at some point yeah and the question is is there a way to achieve that well maybe there is so for that let me introduce the open policy agent uh question here uh who of you already have used open policy agent in a project okay just a few of you that's good so um what is open policy agent uh open policy agent is basically an open source policy engine written in go uh it's basically a a dedicated uh uh server so to speak um to that enables you to evaluate policies validate uh policies and can support a push or pull model to for policy distribution yeah it's basically developed by a company called styra Inc and uh is has been and a lot of community uh developers involved uh and uh I think it's a cncf project for quite a while now and it's it's used all over the place in the cncf ecosystem right mostly for um some use cases include microservice authorization or um in infrastructure an infrastructure as code scenarios uh like U admission controller for cuberes to see whether a certain deployment can be rolled out or not and so on and there are many many other use cases uh just to mention a few uh their main Mantra is uh let us treat policies as code so if we can treat policy or authorization logic as source code we can use all the things that we are used to have with regular source code like we can version it we can lint it we can test it we can refactor it we can audit it and we can run it yeah and that's something um that's that's really cool to have because it uh gives you a uh um um Qui improves the the round trip reduces round trip times and makes it easier to test and and roll out new things in order to do that uh open policy agent supports uh declarative policy language called Rego uh that we will see in a bit um there are some deployment options for for open policy agent first of of course if you are a go project you can rra it uh use it as a go Library uh but mostly you would use it as a side car deployed as a side car alongside your kyllo container and so on and um with that um you are completely um yeah can then configure keyl in such a way to config to speak with open policy agent and a side car in a in a matter that does not have that much latency because usually you you apply this uh side car in a collocated uh deployment or as a collocated deployment the that means the the requests uh are you taking just a few milliseconds uh between the systems uh between the containers and so on yeah okay how does this now work um we have um usually it looks like that we have our service and we have some kind of request or event or whatever that triggers some logic in the service in the application uh the the service uh has a component then that con creates an an access query or policy query based on the request and sends that um access query to the OPA side car the access query can be an arbitrary Json object so you're completely free to use whatever you want here uh the OPA site car itself has uh uh the the policy like the rules uh in Rego in memory uh combined with some maybe additional data like as said additional role hierarchies or roll to permission mappings or other application specific data and whatnot yeah all this data combined like the query the policy and data will then be used to conclude an NEX decision and then uh you will return and the decision the outcome as a Json object again back to your application which is then responsible to enforce that decision yeah that's basically how it goes and now imagine instead of a service we use Klo instead KL is in this case our application for certain cases but let's first uh look at Rego as a policy language just that you get an idea how this would look like um as said Rego is a declarative domain specific language that is inspired by other languages like data lock and prolock like logic programming language and uh it basically consists of a few building blocks which are policies which is are effectively a collection of rules uh a rule is basically a named collection of conditions that are combined WEA and that will get to us in a minute um these conditions uh can be Boolean expressions or calculations of some sort that somehow result in a Boolean um uh result and uh you need to know that there are two implicit variables for us there's this input variable that refers to the object that was given you to you in the policy query and there is this data uh um uh reference to access uh data that is either provided to to Opa or fetched from somewhere else or some other modules that you can see um Opa has built in many functions uh that you can use to solve all sorts of different problems like you can for instance decode or validate a Json web token you can pass Json you can even do things like ack checking whether an IP address is within a certain CER Network range and so on yeah and just to give you an idea how such policy file could look like um it's basically just like that um we have a small text file uh we have a package concept so you can or hierarchically organize your policies and here you see uh uh two rules effectively um um here we have a rule with the name allow uh that defaults to so by default we want to reject all requests if they are not matched otherwise and uh in the second instance of that rule with the same name we say that okay but if the input method is get and the input path is public then uh please um um if this is the case allow requests in that regard yeah so these are the conditions that we have here and one important thing to know about Rigo is that uh or Opa is that uh it tries to match the most specific rule based on the given input yeah this rule is then effectively selected to perform to conclude the um the um result of the the rule so we will see that in action in a second um how do we select op policy um open policies um first um we since we uh use an URL to identify uh the actual policy we have a component that basically selects the policy that in the hierarchy that we provide and we can also provide the the rule in the policy that we want to select um via the URL request path and uh as you you can imagine you can either refer to a policy as a whole and execute all the rules that are contained there or ask for a specific thing if you are just interested in whether we can access certain data Maybe the access rule is sufficient okay uh policy input as said can be any arbitrary Json object as long as it is wrapped in a in an Json object that has an input uh uh attribute and this is usually consisting of identity information or data from the application or the request and uh to execute a policy query you would basically call an grpc or rest API interface uh like in this case we want to we would send a post request um to a certain uh paths let's say let that selects an access policy in our case and here we want to check for the rule allow and as an input we send the current subject the current action uh the current resource like which client we want to access and the context information like which IP address we currently use and whatever yeah that stuff and here's a small example how that looks here have here's a small uh Opa policy in Rego and uh here I want to access for instance um or here I have rules defined that says okay allow is by default default fault so everything that's not explicitly defined here gets denied by default and I have two rules here um if the request comes in with get and to SLU uh I want to allow re public requests uh but if uh request to/ admin uh sent then I need to check whether the current user has the admin role yeah and for instance if I check uh query here internal data uh you see allow is false so access would not be allow to any unlisted uh fth path and if I access public information I can do so by the way uh if you want to see which rules actually were used you can use this open Rego playground here provided by open policy open policy agent project and if you click on evaluate you get actually you get uh a list of the rules that are effectively um touched by the query and uh if I now try to do an admin request you see that ahuh now the this rule is triggered but it failed with this predicate so the is admin was not satisfied and therefore it resulted to false yeah if I now uh say that okay maybe I add the admin Ro to my token to my access token or configure admin access in the application and if I try it again you see ahuh suddenly allow is true and now I can access my resource yeah that's basically how it works so in fact it's quite simple um once you to get around uh how the language works so with that said uh how can open policy agent work with KL well the idea is to use klook as policy enforcement point and opa as the PDP instead of authorization Services um and in this case we use Rego to Define policies in kyl and by the way with this approach this is not just limited to access control logic because some use cases that could be enabled are fine gr admin permissions be replaced with that so I could have basically a policy that says okay when this when this group uh when the user wants to manage this group or added this group he or she has to have this role or be member of the other group yeah just as a text defined um I can also allow or reject identity brokering processes I can also use Opa policies to configure which kinds of claims or assertions are exposed as oidc or sum artifacts yeah um and of course I can use it to manage access for custom endpoints that I put into key clo and of course and that's the use case I will show here in the demo it's I can use it to to limit uh access to certain clients yeah so what are some integration options that we have here of course we could leverage an authenticator authenticator SPI or we could write an required action client policy protocol up we have many many options or we can even extend existing Community extensions like the restrict client off extension and so on but let's see um yeah so for in the following uh I have basically set about the following thing um I have a user in the realm called Opa demo and and klook is configured with an Opa extension um that can then perform access queries against Opa as a PDP and uh evaluate those uh access and it works like that imagine um we want to access a s uh client uh in order to do so uh we would basically uh fetch Pol evaluate a policy that we can find based on the realm name based on some scheme like keylo Realms and opa demo and we want to evaluate the access policy and want to check whether the rule allow evaluates to true yeah that's basically what we have and an access policy could look like that yeah we could say that um allow if the keylo client is app and the client has current Cent Ro access that's all yeah um and uh you see here this KC utils thing that's basically a help structure that gives us some kind of a DSL to easily specify some kind of uh functions that we can leverage here so and how does it now work so if a user now tries to access a certain client like the app here uh we generate this uh input query like we say Okay input is the following we have a subject with the following ID the following username with ram roles client roles uh attributes and so on us this subject wants to access this resource uh uh with this Cent ID and in this realm maybe and the context is here she uses the following protocol the following remote address and is from a staging system or Pro System whatever and all this is then fed into the OPA policy and as a result we get back uh the a access decision like whether the access is allowed or not and we get some metadata alongside with it like the rec a generated decision ID that recorded this interaction and can be used to basically Trace back the interaction for later use okay and with that said now it's time for a demo um here I have a kickl environment running uh with uh three users test guest and admin and uh I have um a few roles like user guest and admin again a few groups and so on yeah and I have clients that show me some use cases so and as a start maybe I want to restrict access to the account console to users that have a certain role like for instance if I use it now um let's see if I access the client application you see it worked and if I look at the Lock you see there was no um oh it's already configured missed uh you see the following uh access query was sent yeah from from the extension that I imp uh configured um so the client in this case the user tester wanted to access the account console um through might connect and um the access was granted because uh the user had the following role because if we look at the policy that is uh associated with that we will see the following yeah I see here I say okay I have a default role allow faults so by default if the client is not explicitly listed there I want to deny access and here I just say okay if the client is account console then the user has to have the ram roll user only then the access is allowed if I change that somehow like use a role that doesn't exist and if I try uh reload uh or try to access it again you will see is denied because the requested role was not found yeah um so and by the way you saw I just edited the policy and it was live immediately uh that why is that um because in this example uh I start open policy agent as a sar container here and just basically watch the policy files that are on the listed on the file system but that's just one way to do it for local testing you can also configure a open policy agent to fetch this policy files from a URL or from a from a from a tar file that you provide uh or from some container format that you deploy in your Docker registry yeah there are many ways to transfer this kind of policies and um yeah and if we look at uh some other use cases here what what what do we have we could just to give you an idea how an access policy could look like so this is an access policy for a client uh this is an access policy for for ab1 that says um yeah if the client is ab1 then we require the client role for ab1 to be access yeah um or to simplify the follow the previous use case a bit we can have an access policy for app two that says okay we want to require the current client the role uh we want to require the user to have the access role for the current client which is app2 in this case yeah and so on and the same goes for for checking whether user is a member of a group um and so on yeah so but now comes a tricky bit and because I said that uh initially um these rules that uh Rego uh specifies here are combined via and yeah so this checks whether the client is app3 and the user is group member of group users yeah but what if you have a more complex scenario where I want to use or yeah um and funny funny thing is uh this language doesn't have an or uh as a as a a predicate as a operator so to speak but you can do something similar you can say that for instance here um I have I have here this helper function special client which checks whether uh the current client the user requesting access to is a special client and then I want to have the F Bar group um and this is basically done by uh defining this function twice this heper function here and in the first first time I check whether it ends with Fu and the second time I check whether it ends with bar and Rigo will basically evaluate both rules and try to satisfy both rules uh and the one that matches uh is then enough let's say uh to make the rule pass yeah that's how you implement or another way to to implement or is uh by using uh set operations like for instance if I want to check whether a client is the account client either being at the the old account backend or the account console yeah and uh that's I can just do with this H function and this serves serves the same purpose yeah so far so good um you might wonder okay that that looks nice and easy how does the how complicated do the helper functions look well that's it yeah the heper functions are mostly on liners that check for one specific value in the input uh most of the time or do some kind of uh uh string cation and then me checks and so on um what what is also possible is to uh leverage the buil-in functionality of Rego for instance to use uh functions like checking for Network um um and so on like here you have this helper function is from Network and I check whether the current IP address belongs to the certain certain CER range yeah and uh the helper of functions for that is also just a oneliner but uses the built-in uh net cider support by Opa and so on yeah and you see you can uh be pretty expressive already with very uh concise code uh without uh writing any additional infrastructure at all here if you have that in place yeah so now you might wonder how how is this done uh how is the access check performed well of course the obvious answer here could be uh to just use uh a custom uh authenication flow yeah that basically uh reps all the authentication uh executors or the components uh in a separate subflow so to speak and then run the OPA authenticator as a required flow afterwards so that's the the most most straightforward solution however um yeah it's quite combersome to have to remodel the authentication flow uh even because most of the time in practice they are already quite complex if you have some customizations in place and uh maybe there are some other means to do that and what I did instead here was to use just a required action uh that I can basically run uh after each browser flow yeah um so regardless how the user locked in whether it was a fresh login whether it was a cookie based login whether it was an identity broker login whatever uh whether it came in with Cabos op connect or or Sul doesn't care this get always executed and with that I can guarantee that access checks are performed properly yeah with a caveat um problem is uh this required actions are currently only exe are executed for the browser flow and for the direct ground flow for some reason um but not for client client flow yeah another question is how when when I want to restrict usage of Grant type password like direct access grants or client credentials Grant how can I do that if I cannot adjust the flow in a way because maybe you maybe some of you don't know you cannot create or currently you cannot create subflows for the client flow here yeah but that's exactly what I would need I would need to wrap all the alternative Flows In A subflow that I can add my Opa access check flow uh check uh authenticator afterwards but this is not possible currently yeah for some reason um I haven't looked into the details yet but it's not possible so so are we stuck now well not quite um because uh there uh is this support for client policy uh in KL which has been added a few years ago or starting a few years ago let's say and uh was is actually intended uh to implement some kind of security profiles for klook like support for the fappy Financial grade API stuff and so on but you can also leverage that uh to create your own uh uh additional logic that is executed whenever a client or interaction happens so in this case here I created an an custom profile profile which I call Opa access profile yeah and in this access profile I have a custom component configured which is called Opa client access policy enforcer and in this here I have uh I configured basically the URL where Klo can find open policy agent and I configured here a template for a policy path that can be used to perform access decisions yeah and uh here I have some additional configuration like I don't know which which attributes should be passed along the the the permission the access request which context attributes should be extracted and so on and I can also say that okay please forward some real attributes please forward some specific client attributes or some specific request headers all this data can then be added to the uh policy query and uh with that I can then basically evaluate my policies so and with that profile in place um I need to activate the profile how how to do that well for that we have the policies as an additional step and here I created an Opa client access policy which says that okay for any client please apply my check access profile yeah and this basically triggers the execution for the policy evaluation as well um and now um if I try some HTTP request here with a gr type password or gr type client credentials you will see click you will see that the policies are in fact evaluated and quered and here we see aha the grand type password was used with the client that configured direct access Grant in this case and uh the same happens uh if I do a CL credentials Grant yeah here you see Grant have Cent credentials with my Cent credentials client yeah and with that I can basically uh restrict all client interactions possible with key CL um and pass them through a policy governed by open policy agent um where I have then now a uniform way to restrict access uh in certain contexts for certain clients huh which is quite nice so um yeah that was uh what I wanted to show in the demo real quick um but there's more so to summarize this were the access request would look like that and of course we would get a corresponding access response that we can then evaluate in our system um and the building blocks that I used was just a required action uh because it's more Universal in that case than just an authenticator which I would need to configure at multiple places maybe or at least with multiple flows um then I configured this um client profile and client policy um with the appropriate configuration and so on yeah but there is more uh how cool is that you can even test your policies without running keylo so you can write tests for your policies um like um I have here um here you see I have the policies configured yeah and here in in a parallel package I have a a policy test yeah um for the access policy and then I can run a tool on the console uh to quickly run the tests and check whether the policies basically evaluate to true in this case uh for the given input that I expect yeah and all that without running keylo that's cool uh and this also allows users maybe to edit their policies and Che Tech test them in a separate application outside of keylo yeah without having to recompile anything yeah okay and yeah of course there are some additional tooling that you can apply here like there's a linta for Rego that uh gives you that checks your code for uh idiomatic uh language usage and of course there's also a mechanism to uh transfer uh policies with data in a package format let's say that can be deployed via Docker Registries so as if you already have a Docker registry in your in infrastructure you can basically deploy a policy open policy container uh fragment there and pull that from from from any Opa instance and uh yeah periodically fetch it uh and check for for for updates and so on yeah okay with that said um I want to summarize authorization services in kylo although I have not shown them but I'm sure if you have used them you know you understand what I mean uh it's practical for some use cases and even required but it's definitely needs better developer experience um there is also there is some support for restricting client access which is a often requested feature I mean almost all of my customers ask me that at some point yeah and as said currently it's possible via the JavaScript authenticators or via the community extensions um and actually what Keo currently is lacking is some notion of an access policy feature right where it can Define um under which circumstances can a user access a client without using authorization services without using uh maybe any other additional system even H but that's uh something for the future the combination of kylo and open policy agent as as I've probably shown you enables flexible uh policy management uh because decisions can now be delegated to Opa and enforced by keyo and we can all leverage all the stuff that is available in the OPA ecosystem which is quite a bunch and yeah it also can have to consolidate existing access logic especially uh if you already are using Opa maybe in your application or for other parts you can share uh access information like when a user can actually use a certain application and maybe move the check forward or and and and so on and the question I always get asked is well does this replace access checks in the application itself and then then I would answer no of course but uh it gives you another option to even check access earlier in the workflow and this enables sometimes new use cases for instances you for instance you could detect that during lockin uh the user is lacking a certain role for a certain application yeah you can detect that in keyo and then instead of just displaying the access Den night page you can basically show a page like okay sorry you cannot access this application but click here to access to request access to the application and then you could basically create an access request email or something like that that gets sent to the manager of the user or the application the person responsible for the client and then the client can maybe uh um uh allow or rejected request and send the user an as email that says okay now your access ACC is granted please try again yeah just because we KL knows that the exess is allowed or not yeah and something like that so and with that I want to say uh thank you um very much uh now it's time for questions uh code and slide you find on git on my GitHub uh and uh yeah looking forward to your questions and thank you very much for your [Applause] patience any questions from the audio uh audience [Music] thanks uh for the presentation um oh close oh yes oh yeah um I have some question regarding the order of the evaluation of this policy because I was thinking of use cases where you want to um enforce policies before the user authenticated and maybe after he authenticated just to see which role he has you have to know the user so he has to lock in to be locked in but um sometimes you want to evaluate some policies beforeand is that possible as well yeah this is possible with the authenticator approach I mean you can place an authenticator in the very at the very top of the authentication flow in this case but uh that comes then with the limitations that I mentioned before that you would need to add this authenticator to all the flows that you require and sometimes it's not so not possible and um yeah um but it's possible to add additional logic there but I used the required action approach to to capture let's say the the last moment before the application leave the user leaves to from kl to the application yeah and uh yeah that works quite well in practice so to speak thank you very nice uh we also played around with Opa a bit uh with keylo and my question was uh can you teach Opa also to not only give like this allow allow through false back but uh also for example if I wanted to enrich my token with some sort of policy yeah yeah yeah yeah yeah okay that's a demo for later or for in the for the afternoon but uh I mean I simplified this quite a bit uh if you if you go more fancy with this you can basically return here an arbitrary Json object like a data structure and you can say in the data structure you can have the information like X is allowed yes or no or true or false and additional information like which Ro was actually missing and so on yeah and or maybe a custom error message and so on yeah that's all possible um but it let's say for the sake of the example I keep it per minimum but it's possible yeah um so yeah my question is a little different um we have planned a very similar architecture just not with keycloak as the p p but as the P PRP so basically offering the policies did you also think about that yet and yeah did you start with that maybe already uh yes or no um yes I thought about that and played with that around I mean that's obvious right you could always have a always also use a have the policy uh have a custom policy enforcer implementation as part of the authorization services and maybe generate even policies from the data that you have there but as said my initial point was that it's quite complicated to use the authorization Service as it is now especially if you have large deployments with many client and many different access rules and it get it um and it gets um let's say crowded quite quickly and it's hard to to to to keep an overview uh and therefore I basically decided to move away from that approach and just use a plain single code based file right that that that defines the X policy for the whole realm but of course this can be extended to okay I could could have also multiple files here for for per client for instance yeah a file per client with a cent policy that only contains maybe this yeah and maybe some the additional Plumbing like this yeah um package stuff that R provides supports but yeah and for me an approach for with code policy as code only uh works better in practice and scales better over time I think but yeah yeah yeah yeah I mean you can build a UI on top of that that generates that files of course that that's always possible right um yeah yeah let the let the Gen AI do the job okay any more questions I'm I'm sorry we we need to uh uh cut the questions here thank you all for the questions we have uh Thomas uh uh for sure for the rest of the day so just ask him and we have this uh open space in the afternoon [Music] so [Music]

Channel: Niko Köbler (@dasniko) - Keycloak Expert

Views: 811

Keywords: keycloak, authentication, auth, oidc, iam, sso, java

Id: O0quO2D2d-E

Length: 48min 35sec (2915 seconds)

Published: Tue Apr 16 2024