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

[Pedro Igor Silva]

On Mon, Aug 20, 2018 at 8:36 AM, Doswald Alistair <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>
> *Sent:* vendredi 17 août 2018 16:26
> *To:* Doswald Alistair <alistair.doswald at elca.ch>
> *Cc:* 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> 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>
> *Sent:* jeudi 16 août 2018 10:30
> *To:* Doswald Alistair <alistair.doswald at elca.ch>
> *Cc:* keycloak-dev <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>
> 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
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>