Repository navigation
Replies: 2 comments 8 replies
|
@mposolda If I understand the documentation right, you could simulate client-specific policies by using client role conditions, couldn't you? |
|
Yes, exactly. Is that sufficient? It is client administrator, who can create client role |
|
@mposolda I think having client administrator able to create client policies is useful. And also having per-client policy directly is probably more intuitive, just wanted to point out that this is already possible with a kind of workaround. |
|
I don't think that we should have client policies per-client. That should just be straightforward client configuration rather than policies. For example if the requirement is to require PKCE for a specific client, just make it a toggle/config on the client, and not something fancy like client policies. Similarly if you want to limit a client to do token exchange only from a list of IdPs, just make it a configuration option. |
|
If a client policy applies to multiple clients, that's just a client policy as we have them today, and it's the realm manager that should configure them, not the client manager. Or, are you thinking more along the lines of the realm manager sets up some mandatory and some optional client policies, then a client manager can choose which of the optional client policies should apply? |
|
No, I was just thinking about a realm manager that wants to say "Client A, B and C" need to use PKCE. Currently, there is just no condition in the policies matching on "Client", only "Client Type", "Client Attributes" and others... |
I see the advantages of client policies that:
But also agree that it has disadvantage, which might be additional complexity in the configuration etc... So maybe let's put this on-hold for now... |
For this use-case, the realm administrator already has some ways how to achieve this. For example, he can create client-policy with the role condition for role |
|
It works, it's just not very self-explanatory it has to be done in this way. ;) |
Uh oh!
There was an error while loading. Please reload this page.
Right now, we have client policies, which could be defined at the realm level (in the admin console in the "Client policies" tab). Hence it is an opportunity for realm administrator to define some policies (For example specify that all realm clients should be FAPI compliant).
I wonder if we can have also the ability to define client policies per client? This will allow that same feature of client policies could be shared for:
The advantage is, that we will be able to use the same mechanism at different levels and we will not need to duplicate some functionality. For example, today there are some switches on the client, which effectively duplicate some functionality available also on client policies. But when having "per-client policies", we will not need to duplicate same switches on the client as the functionality could be defined by client-policy executor.
At the same time, there might be some challenges with this approach. For example assume that we have client-policy executor, which will allow to specify what are allowed identity providers for the external-internal token exchange . Then assume that there are 3 identity providers in the realm named
idp-a,idp-b,idp-c. Then realm administrator want to make sure thatidp-ccannot be used for external-internal token exchange and hence he defines the client-policy executor, which will allow to exchange just tokens issued byidp-aoridp-b. But what if client administrator define also the executor on the per-client policy to allowidp-c? This will contradict what realm administrator wanted to achieve. To avoid this, we will need to make sure that client admin cannot bypass the rules achieved by realm administrator (similar applies for realm administrator not being able to bypass global administrator).Some though about this?
All reactions