search

OHDSI / Atlas

ATLAS is an open source software tool for researchers to conduct scientific analyses on standardized observational data
http://atlas-demo.ohdsi.org/
Apache License 2.0
258 stars 126 forks source link

accept authenticated remote_user from reverse proxy header #2857

Open clarkevans opened 1 year ago

clarkevans commented 1 year ago

For deployments in a cloud environment, user authentication is often upstream of OHDSI tools, including Atlas. By convention an HTTP header can be provided by a reverse proxy, containing the email address of the authenticated user. I suggest that 'X-Remote-User' could be the header name used for this purpose, but I'm not being prescriptive; perhaps it should be a configuration option, that, when left unset doesn't enable this feature.

If this is an easy feature to implement, it is high value, especially for institutions that already have validated security procedures that use reverse proxy authentication.

anthonysena commented 1 year ago

@konstjar @alex-odysseus any thoughts on this?

konstjar commented 1 year ago

My thoughts on this. I would avoid relying or using any (custom) headers for user authentication. It could be a security breach to get access to application including admin permissions.

What I would recommend the following and what was raised in https://github.com/OHDSI/WebAPI/issues/2268#issuecomment-1538866065

  1. Enable SSO (OpenID or SAML) authentication workflow
  2. If WebAPI is configured with OpenID or SAML, we can force user redirect in browser to Identity Provider authentication URL.

This approach was implemented for AtlasGoogleSecurity (GCP Identity Aware Proxy).

But this could be done if only one and single security provider is configured in ATLAS config.

RowanErasmus commented 1 year ago

We are using Azure AD for authentication in Atlas (and many other places) and are also interested in leveraging single sign on. I've made a pr #2861 that will automatically sign in users who already have a session with the auth provider. It is not really (or really not) what @clarkevans is requesting but close to what @konstjar is proposing...

clarkevans commented 1 year ago

My thoughts on this. I would avoid relying or using any (custom) headers for user authentication. It could be a security breach to get access to application including admin permissions.

The standard reverse proxy setup keeps applications like Atlas on a private network that is otherwise inaccessible. What I'm asking for is actually more secure since requests that get to Atlas are already authenticated with high-level authorization... or they don't get past the reverse proxy. What we want is to avoid annoying our user, and continue to use the rest of Atlas user authorization to associate it with roles and other access specific to Atlas.

What would be needed is an exact configuration parameter, say "Remote_User_Header="X-TuftsRemoteUser", that if unset, has the current behavior. If this parameter is set, then the existence of that header will be asserted and its value becomes the username. The reverse proxy would be setting this header, if someone tries to submit this header with another value, it'll be overwritten with what ever authentication the reverse proxy has. Hence, there's no way for this header to be set by the user to bypass security.

This mechanism is standard, a great many web applications have these features, and it permits the reverse-proxy to be the user authentication gateway, centralizing control, etc.