Migrate Keycloak integration to PSA

[mvdbeek]

So that we reduce the integration surface and reduce the number of bugs we fix for each implementation

[jdavcs]

This is relevant to the discussion on refresh tokens in #20821 (I thought this issue would be a good place to post this). The CFDE instance is logging these errors (likely on every web transaction): No `expires` or `expires_in` key found in token extra data, cannot refresh. The reason seems to be this: we are accessing these values as:

if "expires" in user_authnz_token.extra_data

(here); however, in the case of CFDE (auth provider is tapis) the value of extra data stored in the database is a structure that contains refresh_token, which is another structure that contains expires, expires_in, and refresh_token (and this value, most likely, is a non-decodable code). So, for tapis, it would be extra_data -> refresh_token -> expires.

If this requires a separate issue (given that we're getting a ton of these logs), I can open a new issue. Ping @nuwang @natefoo @dannon @kysrpex @martenson

[nuwang]

This looks like something that can be fixed in the tapis specific implementation here:?

galaxy/lib/galaxy/authnz/tapis.py

Line 35 in af2d240

("refresh_token", "refresh_token"),

Most PSA implementations appear to be storing expires, expires_in and refresh_token depending on availability: https://github.com/search?q=repo%3Apython-social-auth%2Fsocial-core%20expires_in&type=code

[lldelisle]

Hi,
I put here my usecase just to give you another example of issue with external authentication. My IdP is ADFS, it is a OIDC but they send the email/username in the id_token instead of in the response so I would need to modify PSA to support ADFS and then add this new class to galaxy.

[nuwang]

@lldelisle Were you using keycloak for OIDC? Now that it has been folded into PSA, PSA's OIDC supports this scenario already: https://github.com/python-social-auth/social-core/blob/d97cdbc99e756dd23e8c1eef4f00e1f72890a7e5/social_core/backends/open_id_connect.py#L370
So if you use the generic OIDC provider, it will hopefully work for you with no extra effort. You can also set the username_key in your provider config if your username is not in the preferred_username field in your token.