1:51 p.m.
On Wed, Feb 6, 2019 at 9:52 AM Alexey Titorenko <titorenko(a)dtg.technology>
wrote:
Hi Pedro!
Thank you for response.
Comments are below.
On 6 Feb 2019, at 14:04, Pedro Igor Silva <psilva(a)redhat.com> wrote:
On Wed, Feb 6, 2019 at 8:31 AM Alexey Titorenko <titorenko(a)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).
It will basically change the the azp and aud claims to the requester and
target service, respectively.
Yeah, there is a real performance penalty if we do that by default.
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.
If you think about the CIP as a "proxy" it is basically forwarding the
token to the claim service, but the actual requester is not the service but
the client that originated the call.
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.
I see now. Makes sense. However, you can make this less painful by using
client scopes where a specific scope can be used to automatically include
whatever claim you need in the token to access the claim(s) services. That
would avoid you to change every single client but just include the scope in
the list of default scopes.
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 :)
Not at all, all valid points !
>
> 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.
Yes, sure.
Thank you for you comments!
Regards.
Pedro Igor
>
> Alexey
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user