[keycloak-dev] Keycloak Modules developed for the Cloudtrust project

Tue Aug 21 04:44:05 EDT 2018

Actually, I am aware of the fine-grained permission functionality, but maybe not when I was asked to provide authorization for access to a client. Whatever the reason, I hadn’t considered using it  before, but it is quite a good fit: it would be a client specific restriction for which policies are used.

Of course, in reality, it is more or less the same as the cloudtrust authorization module, except that it’s resources in the realm management authorization which are used to represent the clients and a new “login” scope which would be used to evaluate the login function. It seems less hacky then my solution, as there’s already a GUI function to create the resource for a given client, and no appropriation of a different functionality . After that I could even reuse my existing code, it would be a matter of getting the correct resource and scope, and the rest of the logic remains unchanged. I’ll look into it when I migrate the authorization module to keycloak 4.X. Of course, if everyone feels that this functionality (or similar) would be better implemented directly into keycloak, I’d be even happier.

Cheers,

Alistair

From: Pedro Igor Silva <psilva at redhat.com>
Sent: lundi 20 août 2018 17:41
To: Doswald Alistair <alistair.doswald at elca.ch>
Cc: stian at redhat.com; keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Keycloak Modules developed for the Cloudtrust project

On Mon, Aug 20, 2018 at 8:36 AM, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:
Hello,

I’ve now received two questions concerning how the authorization module works, so I thought best to answer them both at the same time.

Pedro Igor’s description  (attached below) is broadly correct, but I’ll elaborate more on the principals. As mentioned, it’s a bit hacky. The solutions basically hijacks the existing authorization system used for OIDC clients and UMA, but makes it available to other client types as well.

The initial step is allowing all clients to define authorization rule by giving them access to the authorization GUI. This allows us to use all the policy and permissions’ systems to create rules for the user access. The one thing that must be done is to create the "Keycloak Client Resource" (and indeed define any permission to it) in order to activate the local evaluation for the client. Using a specifically named resource allows us to separate the case from an OIDC client that also wants to use the regular authorization services. The limitation when compared to UMA is that you can’t protect a specific resource, it’s all the client or nothing.

When a user attempts to connect with one of those clients, we let the authentication process continue until the authentication process for keycloak is finished (if it is not already established), but check the authorization status before an actual token is sent to that client. The authorization process (in class LocalAuthorizationService.java) also uses existing systems. We use the current state of the system to construct an AccessToken, which we then submit to an AuthorizationProvider. If the user is permitted to continue, he will receive the token. If not, he will receive a 403 FORBIDDEN. Without the token for a specific client, he should never be able to access that client. But whether the user is authorized for a client or not, the user is authenticated in keycloak, and can continue to enjoy SSO services for any client for which he is authorized.

Of course, this is all only valid for keycloak 3.4.3.Final. I haven’t yet gotten around to checking the changes in keycloak 4.X, and seeing if the system is still valid with the changes to the authorization system. I’ll also readily admit that our current solution lacks polish (and there’s probably some edge cases that we haven’t thought of).

Not sure if you are aware of the admin fine-grained permission functionality, which you can use today to restrict what users can do in the admin console. I think we could leverage this existing functionality by including a specific scope. A scope like "login" would be enough, I think, so you could just associate any policy you want to this scope in order to restrict who/how/when is allowed to authenticate with a client.

@Stian:  for the suggestion of roles, I don’t think it would be much different from our solution while using a role policy, so I could definitely see it working. However, as far as I can see, using policies and permissions allows for more flexibility. By extending the system to client scopes, do you mean allowing a more fine grained control on what information is transmitted for a given user depending on what permissions he has?

Also @Stian:

  *   For keycloak wsfed, we’ll continue updating it as long as we have a use case for it, no problems.
  *   I’ve started on the work necessary to do a pull request for the script mapper. From what I can see, I only need to do some refactoring to use existing methods that would simplify the code, and then I need to see how the other mappers are tested so that I can provide some tests. Someone also told me I need to submit some documentation, so I’ll look into that as well
  *   For the keycloak-export module, I need to discuss it some more with a couple of people. This should happen tomorrow, so I’ll get back to you once I can give you a clear answer.

From: Pedro Igor Silva <psilva at redhat.com<mailto:psilva at redhat.com>>
Sent: vendredi 17 août 2018 16:26
To: Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>>
Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Keycloak Modules developed for the Cloudtrust project

On Tue, Aug 14, 2018 at 6:53 AM, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:

* keycloak-authorization (https://github.com/cloudtrust/keycloak-authorization): this module allows the use of the client authorization system to prevent a user which is authenticated in a Keycloak realm to access a given client. It works no matter which protocol is used, and without the client having to support any extra protocol. Note: this solution is a bit hacky, but necessary for one of our use-cases.

Regarding this extension. if I understood it correctly, it works like that. First from an admin perspective:

1) User creates a client an enable authorization services to it
2) User creates a resource "Keycloak Client Resource" and define any permission to it

From a server perspective:

1) Check if authorization services is enabled to the client to which the user is authenticating
2) Check whether or not permission to access the client is granted

It seems that the main logic for this is at https://github.com/cloudtrust/keycloak-authorization/blob/master/src/main/java/io/cloudtrust/keycloak/protocol/LocalAuthorizationService.java.

Is my understanding correct ? Would like to know if that is how it works today so we can start discussing alternatives.

Regards.
Pedro Igor

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Sent: jeudi 16 août 2018 10:30
To: Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
Subject: Re: [keycloak-dev] Keycloak Modules developed for the Cloudtrust project

On Tue, 14 Aug 2018 at 12:03, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:
Hello,

I just wanted to let this mailing list know that for the Cloudtrust project (https://github.com/cloudtrust), we have developed a certain number modules for Keycloak. These are currently compatible with the version 3.4.3.Final of Keycloak, but we will make them compatible with Keycloak 4.X (where X will be the latest sub-version of Keycloak when we start working on this) as soon as we can. These modules are:

* keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an implementation of the WS-Federation protocol for keycloak. This allows to select the WS-Federation protocol for Keycloak clients and for identity brokers.

This is great and pleased that you are maintaining this. We simply don't have the capacity to have this incorporated into Keycloak as we lack expertise on WS-Fed and have to many other things to maintain.

* keycloak-authorization (https://github.com/cloudtrust/keycloak-authorization): this module allows the use of the client authorization system to prevent a user which is authenticated in a Keycloak realm to access a given client. It works no matter which protocol is used, and without the client having to support any extra protocol. Note: this solution is a bit hacky, but necessary for one of our use-cases.

Sounds interesting. Can you write some more details about this? In the past I've considered if we should have something like required roles to use to a client. That would by not allowing a user to authenticate with a client, but also could prevent adding audience for a service the user isn't allowed to access. Could perhaps take it one step further and prevent client scopes that users are not allowed to access.

* keycloak-client-mappers (https://github.com/cloudtrust/keycloak-client-mappers): a module for adding any mappers that we might need that are not yet part of Keycloak. Currently only contains a JavaScript mapper for SAML, analogous to the OIDC script mapper. I've noticed that there's an open issue for this feature (https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could submit this code not as a module but a solution to the issue.

SAML JavaScript protocol mapper would be great. If you submit with tests and docs we'd love to have this in.

* keycloak-export (https://github.com/cloudtrust/keycloak-export): a module adding an endpoint to fully export a realm while Keycloak is still running (no need for restarts!).

Can you write some more details about this? In the past we've considered this, but not added it mainly for a few reasons, including:

* What happens if there are changes while doing the export, we where thinking we'd have to pause the server from receiving requests during this export
* We don't want a REST endpoint that can return credentials and other secrets. Then there's also the size of the export. It would have to store the export on disc, but then what about clustering. One potential would be to develop a tool that can be executed from anywhere that has access to the db. It would use Keycloak code base, but instead of starting a server it would allow things like running an export from the db, migrate the db, etc.

Cheers,

Alistair

PS: I mailed this to both dev and user mailing lists as I believe it may interest members of both mailing lists. However, upon sending to the dev mailing list the first time it bounced. This is the second attempt.

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev