New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modules user authorization handling #40
Comments
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:
|
|
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. |
MfN decided go for a decentralized authorization for two reasons:
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 :) |
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? |
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. |
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! |
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.
The text was updated successfully, but these errors were encountered: