OHDSI Home | Forums | Wiki | Github

You do not have access to this feature after authenticating with openid for admin user

webapi
atlas

(Michael Shamberger) #1

I am using openid with an azure AD application. I go through the openid flow and my user is logged in. But I cannot access anything in Atlas but Configuration. (had to do some hacks to get it to work. more info at openid not working with webapi/atlas when using Azure AD application · Issue #1711 · OHDSI/WebAPI (github.com)

Clicking anywhere else I see: “You do not have access to this feature.” Any ideas?

I have a log statement in webapi showing my permissions after I inserted a row in the database for my user that was added during the authentication flow.

2020-12-03 15:52:31.919 INFO http-nio-8080-exec-2 org.ohdsi.webapi.shiro.filters.UpdateAccessTokenFilter - - permissions: [source:daimon:priority:get, user:me:get, source:*:get, user:get, source:details:*:get, comparativecohortanalysis:*:delete, source:*:put, role:*:get, user:import:job:*:delete, user:import:job:get, cohortanalysis:post, role:*:users:*:put, cache:clear:get, source:*:daimons:*:set-priority:post, user:import:*:mapping:post, role:*:users:get, user:import:*:post, user:import:*:mapping:get, source:post, user:providers:get, role:get, user:import:job:*:history:get, user:import:*:groups:get, user:import:job:*:get, source:connection:*:get, role:1:permissions:*:delete, user:import:job:*:put, comparativecohortanalysis:*:put, permission:get, source:*:delete, user:import:job:post, user:runas:post, role:post, role:*:users:*:delete, role:1:permissions:*:put, comparativecohortanalysis:*:copy:get, configuration:edit:ui, role:*:permissions:get, user:import:*:test:get, *:person:*:get:dates, user:import:post]


#2

Hi Michael,

unfortunately I cannot help you with your problem. But I have a problem that you might be able to help me with. I am currently trying to authenticate users using openid and keycloack. Unfortunately I can’t get back to Atlas because the WebAPI refuses to authenticate me in the last step.

If I understand the process flow correctly, Atlas gets the location with the parameters response_type, redirect_uri, state, client_id and scope after clicking on openid in the first step. Can you confirm these parameters this way?

Now I have found that I can adjust the redirect_uri using security.oauth.callback.api. Have you also made an adjustment there? There I have entered :/WebAPI/user/oauth/callback. Without this adjustment the redirect_uri will say localhost and port 8080 and the process will abort.

In the next step I authenticate myself with keycloak and get a location returned :/WebAPI/user/oauth/callback/OidcClient with the parameters state, session_state and code.

In the last step this location is addressed and I get a 401 from the WebAPI. Actually the WebAPI should now return a token. At least I think so :slight_smile: I’m not sure if I have to set up anything in keycloak or if I have a general error in thinking.

Here are the security settings i made:
- security.provider=AtlasRegularSecurity
- security.cors.enabled=true
- security.ssl.enabled=false
- security.origin=*
- security.auth.openid.enabled=true
- security.oid.clientId=someID
- security.oid.apiSecret=someSecret
- security.oid.url=oidHostWithRealm/.well-known/openid-configuration
- security.oid.redirectUrl=host:port/atlas/#/welcome/
- security.oauth.callback.api=host:port/WebAPI/user/oauth/callback

I hope I was able to express myself to some extent and thank you for thinking about it.

Best regards,
Mirko


(Michael Shamberger) #3

Hi,
I was able to get openid working with azure. I also had similar issue that I got to the last step and it failed. I tried with github authentication which I was able to get working and was able to see what the urls should look like through the openid flow. I then adjusted the security.oid.redirectUrl and was able to authenicate with openid. chrome developer tools should help you see the last location header prior to the failure. You can select the “doc” filter to avoid seeing all the css/js/png files load.

workaround is to do the following:
security.oid.redirectUrl=https://xxx.xxx.xxx/atlas/#/welcome
to
security.oid.redirectUrl=https://xxx.xxx.xxx/atlas/#/welcome/null/

I have this issue open in webapi github https://github.com/OHDSI/WebAPI/issues/1711.

I also had a problem since I was using a proxy tool that was cause the location header to change from https to http. I fixed this in the nginx by adding a redirect from http to https.


(Ssaranathan) #4

Hi @Mirko, @Michael_Shamberger
Were you able to make any progress on this issue ? I am running into the same issue that you have described. In the last step after authenticating with the OpenID provider, I end up here:
https://xxx/WebAPI/user/oauth/callback/OidcClient?code=4jfVaMQJ0kcvs4bOlxFwg9ULkUUL7j&grant_id=857b0a1d-e529-4f66-9a28-4713512a7d43&state=5By-4OJMv3d-CjS33vlpQSmFfcBAWwa-gdpfu2Ks8Mw

I am not sure what is stopping from getting back to Atlas.

Any help is greatly appreciated.

Thanks,


#5

Hi @ssaranathan,
Unfortunately, I haven’t gotten it to run yet. Are you also using a dockerized deployment?


(Ssaranathan) #6

Hi @Mirko,
Yes, I am using a dockerized deployment in Kubernetes. Thanks


t