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

OpenID authentication + API for authorization #3101

Open
EduardHL opened this Issue Aug 2, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@EduardHL

EduardHL commented Aug 2, 2016

Hi, congratulations for building such a good product.

Would it be possible to authenticate users with any OpenID Connect provider? The PR #2818 is specific to Google. It would be great if we could have something more generic.

To provide more context: we would like to centralise authentication and authorisation in one place for the different front-ends and APIs we provide to our enterprise users. In order to achieve this we are looking at options like OpenAM or CAS. The advantage of having a centralised authentication and authorisation server is that you don't need to duplicate roles and permissions in the different front-ends and APIs. Our enterprise users would ultimately be authenticated with LDAP; using an authentication and authorisation server would allow us to become an OpenID connect provider and check credentials with LDAP. Should #1488 advance further, direct LDAP integration from Metabase could also be an option.

Concerning authorization and related to #3088 and #1175, it would be very interesting for us if there could be a generic API/endpoint that we can implement to check if a user can access a specific resource, in the same way in OAuth 2.0 a resource server (server hosting the protected resources; in this case Metabase) may interact with the authorization server (server issuing access tokens; our central authentication and authorization server) to check if a user has access to a resource; this would avoid defining roles for users and resources directly in Metabase.

Let us know if these widely adopted protocols and solutions (OpenID connect, separating authorisation server and resource server concerns) would make sense for Metabase and how we can help to make it happen.

@salsakran

This comment has been minimized.

Show comment
Hide comment
@salsakran

salsakran Aug 17, 2016

Contributor

regarding " it would be very interesting for us if there could be a generic API/endpoint that we can implement to check if a user can access a specific resource", are you referring to an API you'd program against in a fork? E.g. where for each card that function would call another server and ask if user X could access that item?

Contributor

salsakran commented Aug 17, 2016

regarding " it would be very interesting for us if there could be a generic API/endpoint that we can implement to check if a user can access a specific resource", are you referring to an API you'd program against in a fork? E.g. where for each card that function would call another server and ask if user X could access that item?

@EduardHL

This comment has been minimized.

Show comment
Hide comment
@EduardHL

EduardHL Aug 19, 2016

Yes, exactly. It's good practice in software development to define interfaces (to decouple implementation from how functionality is used throughout the application); it makes your app more modular and easier to refactor sections of the code (which is often necessary sooner than one would desire). In this case it would suffice to have an interface with a method canAccess with two arguments: resource and user. The resource could be a datasource, card or even a dashboard (although it probably makes more sense to define permissions at the datasource/column level and figure out from there if a user has access to a card or dashboard). IMO defining interfaces has very little overhead and many advantages; for example, it would allow other teams contribute plugins (or fork), while you can focus on your target users and let others implement LDAP, other type of visualisations, etc.

EduardHL commented Aug 19, 2016

Yes, exactly. It's good practice in software development to define interfaces (to decouple implementation from how functionality is used throughout the application); it makes your app more modular and easier to refactor sections of the code (which is often necessary sooner than one would desire). In this case it would suffice to have an interface with a method canAccess with two arguments: resource and user. The resource could be a datasource, card or even a dashboard (although it probably makes more sense to define permissions at the datasource/column level and figure out from there if a user has access to a card or dashboard). IMO defining interfaces has very little overhead and many advantages; for example, it would allow other teams contribute plugins (or fork), while you can focus on your target users and let others implement LDAP, other type of visualisations, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment