[keycloak-user] Http CIP and Client's Access Token

Pedro Igor Silva psilva at redhat.com
Wed Feb 6 06:04:16 EST 2019


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.

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.


> 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 ?


>
> 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.

Regards.
Pedro Igor


>
> Alexey
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


More information about the keycloak-user mailing list