Authentication and authorization for IDAC-PL

Science Independent Data Access Centers
#1

We would like to test (and migrate) to central authorization/authentication for polish IDAC. Our current setup uses keycloak which uses github (specific organization) as IDP. As far as I understand we would need client secret and configuration created at USDAC. Details from our side are the following (please let us know if we missed anything):

Following suggestion from Knuth - tagging @rra and @frossie . Would you find some time to help here :slight_smile: ?

#2

These OIDC clients have been set up but are not yet activated yet, since at present we only add new OIDC clients during our weekly maintenance window. I will set them up next Thursday during our patch window and then will message you a URL where you can get the client IDs and secrets to use on your end.

#3

This has been set up and I sent you the credentials via DM.

#4

Hi, thanks for creds, copying went OK. I’ll should be able to test this before end of the week, I’ll let you know

#5

@rra - could you change the redirects to

https://rsp.cis.gov.pl/keycloak/realms/rsp/broker/data-lsst-cloud/endpoint

(for the production site) and

https://rsp2.cis.gov.pl/keycloak/realms/rsp/broker/data-lsst-cloud/endpoint # devel site

(for the development site)?

Apparently my mind went on autopilot while writing the original request :smiley:

#6

This should now be updated. Let us know if you have any problems.

#7

Thanks ! This helped, things got further this time :). I have one minor issue - in the token the actuall issuer is

“iss”:“https://data.lsst.cloud/”

while in https://data.lsst.cloud/.well-known/openid-configuration the “issuer” field lacks tha trailing “/”. This results in the following error in keycloak:

2026-03-23 10:16:07,183 ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (executor-thread-1) Failed to make identity provider oauth callback: org.keycloak.broker.provider.IdentityBrokerException: Wrong issuer from token. Got: https://data.lsst.cloud/ expected: https://data.lsst.cloud

Unfortunatelly it seems once the external idp is configured in keycloak (at least via .well-known endpoint) it is not possible to change the issuer field (keycloak UI gives the possibility, but it seems it is not having any effect). For now correct way is to configure the idp in keycloak by hand (ie without using well-known for automatic configuration), with correct issuer from start. In longer run - would you be able to make entry in .well-known/openid-configuration consistent with the one in token?

For another thing I’m not exactly sure if it is another keycloak problem or bug on our side (understood as rsp stack - most likely in gafaelfawr - and not this specific deployment) . After workarounding the issuer problem I get the following error visible in keycloak logs:

2026-03-23 10:27:21,735 ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (executor-thread-6) Failed to make identity provider oauth callback: org.keycloak.broker.provider.IdentityBrokerException: Could not fetch attributes from userinfo endpoint.

(…)
Caused by: java.lang.IllegalArgumentException: Last unit does not have enough valid bits
at java.base/java.util.Base64$Decoder.decode0(Base64.java:872)
(…)

I saw this earlier while debugging the first issue - at least one part of the “id_token” does not contain base64 padding. Please compare the results of:

echo eyJhbGciOiJSUzI1NiIsImtpZCI6ImdhZmFlbGZhd3IiLCJ0eXAiOiJKV1QifQ | base64 -d # the actual part of the token
→ {“alg”:“RS256”,“kid”:“gafaelfawr”,“typ”:“JWT”}base64: invalid input

and

echo eyJhbGciOiJSUzI1NiIsImtpZCI6ImdhZmFlbGZhd3IiLCJ0eXAiOiJKV1QifQ== | base64 -d # padding added manually
→ (proper decode, without base64 warning message)

Do you happen to know if openid standard requires padding to be present? This determines if I should open a keycloak issue or this should be fixed on rsp stack side

#8

Hi Tomasz,

The first problem (the mismatch of issuer because of the trailing slash) is definitely a bug. I’ve found the problem and it should be fixed in our Thursday maintenance window this week.

For the second, could you double-check that the error is coming from decoding the id token? JWT requires use of base64url encoding, which prohibits adding padding, so it would be weird if a major implementation such as Keycloak were complaining about that. See:

https://www.rfc-editor.org/rfc/rfc7515.html#section-2

under Base64url Encoding. I suspect it’s complaining about some other part of the userinfo response, but I’m not sure what it might be complaining about. Although, that said, I’m not sure what else it might be trying to decode, since the other values returned from the userinfo endpoint are not base64-encoded.