[keycloak-dev] OAuth2 Incremental Authorization

[Schuster Sebastian (INST/ESY1)]

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 at 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 at redhat.com] 
Sent: Mittwoch, 25. April 2018 18:37
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
Cc: Pedro Igor Silva <psilva at redhat.com>; Thorgersen, Stian <stian at redhat.com>; keycloak-dev <keycloak-dev at 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 at 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