Modules user authorization handling

[cgendreau]

All DINA modules will require some kind of authorization. A simple example could be: A collection manager should only have access to the data of its collection (at least for modifications).

This is already implemented in SeqDB and the current plan was to delegate it to KeyCloak eventually. In SeqDB each "entities" in the database belong to a "group" then, depending on your group "membership" and ACL, you are authorized (or not) to perform an action.

I'm fairly convinced that all modules should use KeyCloak for authentication AND authorization but the purpose of this issue is really to start the discussion.

[antonoberg]

Falko said that in Berlin they made the decision to handle authentication in KeyCloak but authorization outside KeyCloak. Would be interesting to know why they went that path. In Sthlm we will soon dive into this within our mvp. Before starting this i have 3 questions:

• Do we wrap KeyCloak to make it json-api compliant?
• Do we handle authorization in KeyCloak?
• Do we put non core user-data like user preferences, which could be everything from prefered font-size to custom shortcuts to saved queries, in KeyCloak or do we put it in a separate service.

[gnewton]

• Do we wrap KeyCloak to make it json-api compliant?
  No. This decision was already made: https://github.com/DINA-Web/guidelines/blob/master/DINA-Web-API-Guidelines.md NB: Non DINA implemented module ( i.e Keycloak, SOLR ) do not have to comply with this specification.

• Do we handle authorization in KeyCloak?
  Yes. It is designed to do this and it does it well.

• Do we put non core user-data like user preferences, which could be everything from prefered font-size to custom shortcuts to saved queries, in KeyCloak or do we put it in a separate service
  I don't see why not.

[gnewton]

Completely agree.

To be clear, KeyCloak handles all authentication, but in many cases it will be delegating authentication to one (or more) primary authentication services.
For authorization, I believe all authorization should be implemented in KeyCloak. It supports very rich authentication models.

[falkogloeckler]

MfN decided go for a decentralized authorization for two reasons:

• In some services there might be specific permissions beyond CRUD. This means a centralized service for authorization like KeyCloak would need to "know" all these special permissions of each service in order to be able to assign them to the users. This would be also true for user fine-grained user roles.
  For example: If an interface is highly customized for suiting different use cases, there might be features like permissions per field. Thus, all field permissions would have to be exposed to KeyCloak and the interface will still need to perform the respective action (e.g. display the field or make the field writable) as far as the user has the persmission. Depending on the granularity, this would be a huge overhead.
  If noone has such fine-grained permissions in a service - that's good! But we all might know exceptions that our clients usually require....

• A centralized management tool for authorization sounds attractive, but does anyone have experiences in how this works in practice on the long run? At least at the MfN we have the experience that in (historically grown) infrastructures, the user groups and roles can accumulate quite quickly. So it might end in redundancy and/or double-assignment of permissions to groups, so that some users could accidentally have too many permissions in some unlucky cases. (At least a proper and well-documented naming convention for groups and roles is essential for avoiding this).
  We assume that it is easier having the permissions of users or user groups managed by (local) administrators per service (or module) as this might minimize the risk messing things up globally.
  For sure there are pros and cons on both sides and you can mess things up with both approaches ;)

Maybe I still don't know good enough KeyCloak's capabilities and all the above-mentioned issues can be easily solved by using KeyCloak. So, feel free to convince me :)

[antonoberg]

In our iterative approach I think we want to start by using KeyCloak for both authorization and authentication but keep custom user data in another service (data like savedQueries and user interface preferences).

@gnewton What do you mean with: "To be clear, KeyCloak handles all authentication, but in many cases it will be delegating authentication to one (or more) primary authentication services."?

What stuff do you see could be delegated?

[falkogloeckler]

"...it will be delegating authentication to one (or more) primary authentication services."

As far as I understood, @gnewton refers to Keycloak's capability of being a broker for different authentification providers like MS Active Directory and other LDAP servers, OpenID, Social Media Platforms, GitHub etc.
So all DINA services only need to "talk" to Keycloak and Keycloak is the only service that "talks" to the desired authentication providers.
As soon as an authentification provider changes its endpoint or specifications (e.g. like Facebook does from time to time) only Keycloak has to be re-configured or adapted, but not all other DINA services. Further the authentication with Keycloak would be much more unified across the DINA services and code.

[gnewton]

I do not consider "data like savedQueries and user interface preferences" -@antonoberg, to be authorizations or authentication data, so would prefer it not to be in or mediated by keycloak.

And, what regarding delegation, @falkogloeckler said!
We want to avoid a fan-out from each service. They should use keycloak and any fanout via delegation should happen there.