Ctfreak OIDC support

[jypelle]

Insert directly into the database? I'll have nightmares if we choose that path

I suggest going through the API instead (which will keep the script functional in case of modifications made to the database in future revisions).

On a new running instance of ctfreak (which still has its default admin account), we should launch (only once):

# Install jq & curl
apt install jq curl -y

# Retrieve access token for default user 'admin'
API_ACCESS_TOKEN=$(curl -s --request POST --url 'http://localhost:6700/api/v1/token?grant_type=password&username=admin&password=ctfreak' | jq --raw-output '.access_token')

# Add cloudron auth provider
curl -s --request POST \
  --url http://localhost:6700/api/v1/authProviders \
  --header "authorization: Bearer ${API_ACCESS_TOKEN}" \
  --header 'content-type: application/json' \
  --data '{"name":"Cloudron","enabledFg":true,"authProviderType":"OIDC","oidcAuthProvider":{"clientId":"'$CLOUDRON_OIDC_CLIENT_ID'","clientSecret":"'$CLOUDRON_OIDC_CLIENT_SECRET'","discoveryEndpoint":"'$CLOUDRON_OIDC_DISCOVERY_URL'"}}'

Options to add to manifest:

"oidc": {
    "loginRedirectUri": "/oidc/callback",
    "logoutRedirectUri": "/",
    "tokenSignatureAlgorithm": "RS256"
}

(I haven't tested it with cloudron)

[girish]

@jypelle thanks I will give this a try.

[vladimir.d]

@jypelle I've added OIDC configuration to the app (using REST API) but it doesn't seem to work. I get Unable to create external user error. Maybe it needs some autocreate flag initialised as well?

[jypelle]

@vladimir-d

In the logs, you should have a line of the following type:

Unable to create external user: ...

Can you provide its content?

Also:

• Which authentication provider do you use?
• Is the name of your user properly defined in your authentication provider (empty username could be the cause of the error) ?

[vladimir.d]

@jypelle There is "Unable to create external user: User full name is empty" error in the logs.

The authentication provider is Cloudron. Cloudron OIDC details are set by curl request as above. They are set correctly in admin UI.
I'm able to successfully log in at Cloudron, then it redirects me back to ctfreak instance and I get the above error.

I suppose it's not properly set the fullname attribute, it should be mapped to name from configuration details provided by ${CLOUDRON_OIDC_DISCOVERY_URL} https://CLOUDRON-INSTANCE/openid/.well-known/openid-configuration.

Is it possible to specify the attribute to map fullname to using REST API?

[jypelle]

I think I have identified the problem: profile scope claims are missing from the OIDC ID token.

I use a cloudron test instance (https://my.testserver.local) and a ctfreak test instance (http://localhost:6700)

Ctfreak calls authorization endpoint (with scope = openid + profile) :

https://my.testserver.local/openid/auth?client_id=aaa&redirect_uri=http%3A%2F%2Flocalhost%3A6700%2Foidc%2Fcallback&response_type=code&scope=openid+profile&state=01H2V4MCC81YQM1ZEZK9RZNZM6

And receive this ID token through its callback URL:

{
  "sub": "testserver",
  "at_hash": "92ETIwTQXH87k71vUy5h_Q",
  "aud": "aaa",
  "exp": 1686689235,
  "iat": 1686685635,
  "iss": "https://my.testserver.local/openid"
}

=> The attribute "name" is missing even though the "profile" scope was requested.

(FYI, "given_name" and "family_name" are missing too even though Ctfreak doesn't use them)

@girish is there a way to add this attribute in the OIDC implementation of Cloudron (this field is filled in the Google and Microsoft OIDC implementations) ?

[nebulon]

We are internally using the oidc-provider node module and I guess this bit of the docs explain why its missing https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#conformidtokenclaims

the response_type in your case is code not id_token. But I will test tomorrow if we can disable that hard requirement to be more aligned with the behavior of the big providers here.

[jypelle]

Noted, @nebulon , thank you for the feedback.

Apparently, according to the OIDC Spec, claims should be returned when no access token is issued, so not only in the case of response_type=id_token:

"However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token"

For response_type=code, an authorization code is returned, not an access token.

[nebulon]

Indeed from that spec it seems like it should, but maybe only in the second step when requesting a token using the returned auth code? At least this is what is indicated at https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660 in section 1. response_type=code

[nebulon]

I have now tested the oidc branch of the app with https://git.cloudron.io/cloudron/box/-/commit/33c1b4ae3b55b71d329b7cbdb51d94b2bd9d4731 and the login works now fine.

Just need to test other apps, to ensure the behavior does not break them. Then we can include this in the next Cloudron release.

[jypelle]

Great! Thx @nebulon

[jypelle]

I have released ctfreak 1.10.1 to facilitate integration with Cloudron: there is no longer a need to wait for the next Cloudron release to enable OIDC.

Here are the details:

https://git.cloudron.io/cloudron/ctfreak-app/-/issues/1

[nebulon]

I will mark this as solved as the latest package has a great integration now! Thanks