OpenId Logout not terminating OIDC Session

robinmohlePOP commented 10 months ago

Expected behavior

Click logout Click login Redirected to external application prompts for credentials (we are using keycloak) Login

Actual behavior

Click logout Click login Redirected back to atlas instead of the external application login screen (because the session is still active in the external authorization application (keycloak))

Environment variables

# OAuth
SECURITY_OAUTH_CALLBACK_UI="https://.../atlas/#/welcome"
SECURITY_OAUTH_CALLBACK_API="https://.../WebAPI/user/oauth/callback?client_name=OidcClient"

# OpenID
SECURITY_AUTH_OPENID_ENABLED="true"
SECURITY_OID_CLIENTID="ohdsi"
SECURITY_OID_APISECRET="..."
SECURITY_OID_URL="https://.../auth/realms/CDEP/.well-known/openid-configuration"
SECURITY_OID_LOGOUTURL=
SECURITY_OID_EXTRASCOPES="roles"
SECURITY_OID_REDIRECTURL="https://.../atlas/#/welcome/null/"

We are hosting from docker using Broadsea

We are successfully hitting org.ohdsi.webapi.shiro.filters.LogoutFilter (confirmed with debug logs), but the filter isn't logging out the OIDC Client because the next attempt to login immediately results in a login (no prompt for credentials).

thoniTUB commented 7 months ago

Hey @robinmohlePOP, quick side question: Does setting SECURITY_OID_EXTRASCOPES="roles" work for you?

I cannot get it to work:

In the IDP (Keycloak) I created a user and added the admin role.
I set SECURITY_OID_EXTRASCOPES="roles" and the scope roles is also included in the token by default.
When I login to Atlas the user is created successfully, however it has only the default public role (and the personal role) in the webapi/Atlas.

I looked into the code of webapi and couldn't find a spot, where the roles could be transfered from the token to the created user. I suspected the role mapping here https://github.com/OHDSI/WebAPI/blob/3f9e90c5a62dac4557f34f85b2d0ce70d58b439d/src/main/java/org/ohdsi/webapi/shiro/filters/UpdateAccessTokenFilter.java#L58

chrisknoll commented 7 months ago

There isn't a way to do this out-of-the-box, tho it does make sense to have some sort of 'default user role rule' somewhere in the codebase, tho making that rule logic based on an arbitrary attribute of the authentication provider does not seem tenable.

What we do in-house is we have a trigger set up on sec_user, such that when a new user is added we apply default permissons. It's possible you could have a custom lookup table that would be used to assign default user roles based on some userID lookup.

thoniTUB commented 7 months ago

Thank you for the insight! I was hoping that it somehow works.

Regarding the default role, I saw that there is the possibility to set this for User Import from AD via SECURITY_AD_DEFAULT_IMPORT_GROUP="public". Actually this is a list, so multiple roles can be set. Unfortunately this variable only applies to AD Import. I'll open a proposal to define property, that covers all authentication.

OHDSI / WebAPI