Ctfreak OIDC support
-
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)
-
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)
wrote on Jun 12, 2023, 2:14 PM last edited by@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 someautocreate
flag initialised as well? -
wrote on Jun 12, 2023, 5:21 PM last edited by
@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
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) ?
wrote on Jun 13, 2023, 9:08 AM last edited by@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?
-
wrote on Jun 13, 2023, 8:24 PM last edited by jypelle Jun 13, 2023, 8:41 PM
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) ?
-
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 iscode
notid_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. -
wrote on Jun 14, 2023, 7:05 AM last edited by jypelle Jun 14, 2023, 7:09 AM
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.
-
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
-
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.
-
wrote on Jun 21, 2023, 8:38 AM last edited by jypelle Jun 21, 2023, 8:39 AM
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:
-
-