GitHub user user1500177 added a comment to the discussion: Title: OAuth/OIDC
Access Token (RS256) Rejected by /api/v1/security/csrf_token/ with "The
specified alg value is not allowed
@rusackas @rdubois @dosu
I had successfully configured the Supeset to use Zitadel as the OAUTH provider.
And the common users(In Zitadel under my application) are able to login via the
UI successfully.
AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
{
'name':'ZitadelSSO',
'token_key':'access_token',
'icon':'fa-address-card',
'remote_app': {
'client_id': client_id,
# Client Secret is generally omitted when using PKCE
'client_kwargs':{
'scope': 'openid profile email',
'code_challenge_method':'S256'
},
'api_base_url': f'{domain_url}oidc/v1/',
'access_token_url': f'{domain_url}oauth/v2/token',
'authorize_url': f'{domain_url}oauth/v2/authorize',
'jwks_uri': f'{domain_url}oauth/v2/keys'
},
}
]
I had created an automation script to upload dashboards to superset but its not
working with the PAT from the service user account of Zitadel [Error is "Not
enough segments"]
Then i utilized the id_token that is taken from the userinfo endpoint of
Zitadel for providing the addtional information (Like the Zitadel role and all
and then i later mapp that user to Admin or Gamma etc), With the exact same
id_token that the user can use to sign in to Superset (via Zitadel ) also we
are not able to obtain the csrf_token BY USING the id_token as the access_token
in the request.
The uploading of dashboards is working well when its a 'db' user {When Zitadel
was not set up}, while sending the request to endpoint and flow like ::
ACCESS_TOKEN=$(curl -s -k --request POST --url
https://<SUPERSET_DOMAIN>/api/v1/security/login --header 'accept:
application/json' --header 'authorization: Basic Og==' --header 'content-type:
application/json' --data '{
"username": "username",
"password": "passwordofuser",
"provider": "db"
}' | cut -d: -f2 | cut -d\" -f2)
CSRF_TOKEN=$(curl -k -s -c cookies.txt --request GET --url
https://<SUPERSET_DOMAIN>/api/v1/security/csrf_token/ --header 'accept:
application/json' --header "authorization: Bearer $ACCESS_TOKEN" --header
'content-type: application/json' | cut -d: -f2 | cut -d\" -f2)
curl -k -s -b cookies.txt --url https://<SUPERSET_DOMAIN>/v1/dashboard/import/
--header 'accept: application/json' --header "authorization: Bearer
$ACCESS_TOKEN" --header 'content-type: multipart/form-data' --header
'referer: https://<SUPERSET_DOMAIN>' --header "x-csrftoken: $CSRF_TOKEN"
--form 'formData=pathfordashboard.zip' --form overwrite=true --form
'passwords={"Something": "Something"}'
1) I saw that a person can only use the "provider" parameter or header as the
"db" or "ldap" , will support for the custom configured Zitadel or other OAUTH
be given in the following updates
2) When i checked I also came across materials that the ACCESS_TOKEN from the
db provider is HS256 signed JWT and using it in request for CSRF_TOKEN is
correctly responding, But using the id_token (of the Zitadel which is a RS256
signed JWT ), we are not able to login the user via the
https://<SUPERSET_DOMAIN>/api/v1/security/csrf_token/ endpoint AND the error
comes up like {"msg": "The specified alg value is not allowed"} , EVEN THOUGH
the same user is able to sign in to superset with Zitadel
3) My whole aim was to sign in a service user who has a PAT or JWT(which is
also the RS256 signed one), as i have already configured the OAUTH correctl and
user can login ia the UI , I DID expect the endpoints to work too , BUT I GUESS
SOMETHING is preventing me from getting the csrf_token from the
endpoint(https://<SUPERSET_DOMAIN>/api/v1/security/csrf_token/ , with the
access token form Zitadel or JWTs from Zitadel), **IS IT BECAUSE THE SUPERSET
expect only the HS256 signed access_token (THATS WHAT I UNDERSTOOD , CORRECT ME
IF I AM WRONG please....) in the request made to the same csrf endpoint (Which
as of now will be got from the https://<SUPERSET_DOMAIN>/api/v1/security/login
endpoint and the with the provider options available as "db" OR "ldap"?? )**
[REPSOND TO THIS QUERY PLEASE]
**4)Is it possible to create a new endpoint via the superset_config, that could
be used for uploading the dashboards, by verfying the PAT directly , is that
possible or not possible ?**
5)Have any one encountered similar problem in the past and solved it ?
GitHub link:
https://github.com/apache/superset/discussions/35281#discussioncomment-14523044
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
