[keycloak-user] Http CIP and Client's Access Token
titorenko at dtg.technology
Wed Feb 6 06:52:31 EST 2019
Thank you for response.
Comments are below.
> On 6 Feb 2019, at 14:04, Pedro Igor Silva <psilva at redhat.com> wrote:
> On Wed, Feb 6, 2019 at 8:31 AM Alexey Titorenko <titorenko at dtg.technology> wrote:
> Hello guys!
> Could someone please help me with my investigation of PolicyEnforcer?
> I’m currently checking how ‘http’ claim information point is working.
> Let’s imagine typical situation when some client calls service, which, it turn, uses ‘http’ CIP. That is, we have following scheme: CLIENT -> Service -> ClaimSerivce
> The question is about the token, which is used to call ClaimService. I would expect, that Service should get its own token which provides access to ClaimService. But I see, that it uses CLIENT’s token. Which imho means, that:
> Client knows from his token about this ClaimService although he shouldn’t from the security point of view. Although, it some schemes it may be required, I agree. But not always.
> Service calls ClaimService using not his own rights, but client’s rights, which makes it more difficult to control and audit access.
> I see your point. However, the "http" CIP is just forwarding the client token in order to fetch from the claim service whatever claim associated with the subject represented by the token. We could easily support token exchange prior to a request to the claim service, but I think most of the times you just want to identify the subject and then resolve claims based on it.
Ok, I see. Sounds reasonable.
I have not played yet with token exchange… Can we use something similar to ‘on-behalf-of’ with token exchange? When Service exchanges Client’s token to a token issued to Service acting on behalf of Client? I my opinion it would be just perfect case, although, with performance penalty (which is +1 for current way).
> The main point here is that the claim service does not really provide a public API accessible for other components but services that are doing contextual authorization.
My point here is that internal services, including Claim Service, should also be secured and we should be able to control who can and who did access the Claim Service, ideally, in the same manner as we do for other services. Otherwise, we need to compensate this difference by network configuration, which only allows access to the Claim Service to a set of known services or use other means. Also, we cannot audit calls based on token, as it does not represent actual caller of the Claim Service.
I see the idea of this implementation. In some cases it can be OK, In others we might need to add token exchange using current implementation as a reference.
> Usage of ClaimService is an internal detail of the Service and may change at any time. In this case we need to reconfigure tokens for all clients calling Service, which is, again, not good.
> Could you elaborate more about this, please ?
Currently, my Service uses Claim Service to obtain some claims for Client. If Service implementation change, including security requirements, it may start using another ‘New Claim Service’ or many services for different claims or not using them at all any more. So, if I changed my Service, then I still need to ensure, that Client’s token also new roles for new Claim Services and so on.
Resuming, if I change some service implementation, I’m OK with the need to change those clients (their config is Keycloak) which directly invoke it. But it might be a problem when I need to also changes those, which do not directly face changed service. It might be complicated if we have complex infrastructure with hundreds of services.
At this moment I’m only elaborating safe, clear and systematic ways to use Keycloak in our projects.My understanding is not good yet. Sorry, if I say stupid things :)
> What do you think about this? Am I right or wrong? Or should we consider OOTB 'http' CIP as a reference only?
> Also, http CIP does not support path parameters, which is typical situation for REST. Only query parameters.
> You can use it as a reference and create your own based on it. Depending on what you have we can discuss including your changes to upstream.
Thank you for you comments!
> Pedro Igor
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
More information about the keycloak-user