5:52 a.m.
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).
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.
Yes, sure.
Thank you for you comments!
Regards.
Pedro Igor
Alexey
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
<https://lists.jboss.org/mailman/listinfo/keycloak-user>