I still think this should be handled centrally inside Keycloak. I would just tie it to
roles or any other token mapper generating a specific claim. Something in the line of the
client requests a token, Keycloak finds out that the claims to be added to the token
requires a certain security level, looks up the policy for that level and e.g. performs a
stronger authentication if required for that level.
Assigning roles/claims to security levels would have to be done by the service developer
since only he knows what these claims give access to. We would probably base this on
security classifications we have to define for all data we handle anyways.
However, you are right, the policies necessary to get access to certain classification
should be defined centrally and not only based on strength of authentication but might
depend on things like location, internal/external network and the like...
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: Bill Burke [mailto:bburke@redhat.com]
Sent: Mittwoch, 25. April 2018 18:37
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
Cc: Pedro Igor Silva <psilva(a)redhat.com>; Thorgersen, Stian
<stian(a)redhat.com>; keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] OAuth2 Incremental Authorization
On Wed, Apr 25, 2018 at 12:05 PM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com> wrote:
I think security levels should not be tied to client scopes directly
because they represent the client's view (what he needs to ask for). Security levels
should be bound to the resource servers view because he in the end decides what level of
authentication is necessary to get access, e.g. by means of having certain roles in the
token... However, I would like that feature.
So you think that security levels are decided by the app and not the administrator? That
an app would request a certain security level rather than the adminstrator mandating it?
IMO, I would think that it would be better practice to have this metadata centralized and
driven by Keycloak rather than have the logic in the application. That way all the
complexity is centralized too and there's a lot less coding the app/service needs to
do. Think about it...if the app or service decided on security levels, then any change in
security policy would require a refactor of the app/service and a respin/redeployment of
it.
If everything is centralized then the app or service never needs to be touched and can
remain running. Security policy changes become immediate.
--
Bill Burke
Red Hat