Hi,
In the panel " Identity & Access Service Provider Management" doing the Verify I have this error from third party Oauth:
What action I have to take ?
Thanks
Could you provide a browser trace from the browser’s developer console which shows the network calls being made? We could then see the scopes being requested.
Which OAuth/OIDC identity provider are you testing against?
Sorry for the delay I think third party oauth have missing configuration, they are resolving. I will updated you. Thanks.
HI @cbakeley,
also this error I think is a missing configuration…
Now I have this kind of error:
@EdgarCap : That error is coming from your target OAuth service. It’s not a VAL error. I suggest you contact your OAuth service provider for more information about what error message means.
1 Like
Yes, I have contact them, hope they can solve.
Many thanks.
Hi @cblakeley,
finally I have this error on the ACCESS Token CALL: 400
POST /openam/oauth2/realms/root/realms/OpenData/access_token HTTP/1.1" 400 199
Scope parameter is not supported on an authorization code access_token exchange request. Scope parameter should be supplied to the authorize request.
** at org.forgerock.oauth2.core.exceptions.OAuth2Exception.toChfException(OAuth2Exception.java:120)**
D]org.forgerock.oauth2.restlet.OAuth2ChfException: Scope parameter is not supported on an authorization code access_token exchange request. Scope parameter should be supplied to the authorize request.
at org.forgerock.oauth2.core.exceptions.OAuth2Exception.toChfException(OAuth2Exception.java:120)
at org.forgerock.oauth2.restlet.TokenEndpointResource.token(TokenEndpointResource.java:110)
at jdk.internal.reflect.GeneratedMethodAccessor259.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegating
…
How we can debug the Virtuoso no trace of this calls.
The final error on Virtuoso is:
Hi @cblakeley,
problem solved, but I think there is something wrong in the access_token oauth call because was passed the “scope” but “scope” is not one of the parameter accepted in the access_token CALL.
Ref:
https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3
The client makes a request to the token endpoint by sending the following parameters using the “application/x-www-form-urlencoded” format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:
grant_type REQUIRED. Value MUST be set to “authorization_code”.
code REQUIRED. The authorization code received from the authorization server.
redirect_uri REQUIRED, if the “redirect_uri” parameter was included in the
authorization request as described in Section 4.1.1, and their values MUST be identical.
client_id REQUIRED, if the client is not authenticating with the authorization server as described in Section 3.2.1.
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described
in Section 3.2.1.
Also:
Sebastian,
Re: your last post and subsequent email:
I found that the call of Virtuoso to our access_token endpoint is:
#curl -d "grant_type=authorization_code &code=REaJ1YSh4ViWtK54SnaP5_daR_8 &redirect_uri=http%3A%2F%2F<HOST>%3A8890%2Fval%2Fapi%2Fthirdparty_callback &client_id=xxxxxxxxxxx.opendataclient&client_secret=xxx &scope=openid%20email%20profile" -X POST https://<END-POINT>:8443/openam/oauth2/realms/root/realms/OpenData/access_token -k {"error_description":"Scope parameter is not supported on an authorization code access_token exchange request. Scope parameter should be supplied to the authorize request.","error":"invalid_request"}Why Virtuoso is sending also the parameter “scope” (is not allowed) to the access token endpoint?
Looking at the OAuth 2.0 spec, the token endpoint does accept a scope parameter, but it depends on the grant type being used.
RFC6749 OAuth 2.0 Section 3.3 Access Token Scope
The authorization and token endpoints allow the client to specify the scope of the access request using the “scope” request parameter. In turn, the authorization server uses the “scope” response parameter to inform the client of the scope of the access token issued…The authorization server may fully or partially ignore the scope requested by the client…
RFC6749 OAuth 2.0 Section 4 Obtaining Authorization lists the forms of access token requests for different grant types.
Access token requests using Resource Owner Password Credentials Grant or Client Credentials Grant allow a scope parameter. That for Authorization Code Grant doesn’t require scope. However I’m surprised the OpenAM Authorization Server doesn’t ignore the redundant scope parameter supplied with the access token request when Authorization Code Grant is used.
As a workaround you could try modifying procedure VAL.DBA.oauth_token and comment out the addition of the scope parameter to the request parameters.
~line 82:
if (not isnull (scope))
params := params || sprintf ('&scope=%U', scope);
/cc @hwilliams
Hi Carl,
thanks for you help, however I think this is a little bug of Virtuoso for this specific case. I ask my IAM group what is the version of OpenAM we are using right now.
Hi @cblakeley ,
I modify the procedure as you suggest, look the attachment, but now I get thin error: “ Error: Failed to fetch service ID from service "ServiceName" (My Service name).
All the calls are ok:
GET /openam/oauth2/realms/root/realms/OpenData/authorize?redirect_uri=http:///val/api/thirdparty_callback&client_id=xxxxxxxxx&state=cd0ba55a481b39c3fc460df92838b039&response_type=code&scope=openid%20email%20profile&nonce=b2fa2904dab252d66d49c951a35f6cca HTTP/1.1" 302 –
POST /openam/oauth2/realms/root/realms/OpenData/access_token HTTP/1.1" 200 1502
GET /openam/oauth2/realms/root/realms/OpenData/userinfo?scope=openid%20email%20profile HTTP/1.1" 200 30
What I am missing ?
Error line 1012 of VAL.DBA.thirdparty_callback …
if (DB.DBA.is_empty_or_null (serviceId))
** signal(‘22023’, sprintf(‘Failed to fetch service ID from service “%s”.’, service));**
Regards.
Sebastian.
@EdgarCap : Are you able to capture the HTTP request and response (including http headers) from the GET to /openam/oauth2/realms/root/realms/OpenData/userinfo?
Could you also add debug output to procedure VAL.DBA.oauth_id_token to include
--- oauth_id_token.git.sql 2022-10-05 16:19:27.000000000 +0100
+++ oauth_id_token.debug.sql 2022-10-05 16:23:05.000000000 +0100
@@ -20,7 +20,7 @@
inout newEmail varchar,
inout profileProps any)
{
- -- dbg_obj_princ ('VAL.DBA.oauth_id_token (', id, id_token, token, ')');
+ dbg_obj_princ ('VAL.DBA.oauth_id_token (', id, id_token, token, options ')');
declare N integer;
declare tmp, params, data, jwks any;
declare nonce, returned_nonce, webid varchar;
@@ -76,6 +76,7 @@
tmp := http_get (VAL.DBA.prepare_url (userinfoUrl, params), header, 'GET', sprintf ('Authorization: %s %s', token_type, token));
commit work;
data := DB.DBA.json2obj (tmp);
+ dbg_obj_princ(current_proc_name(), ', data: ', data);
_skipUserinfo:;
webid := get_keyword ('webid', data);
then provide the Virtuoso console output?
Ok, the response of the GET OF /openam/oauth2/realms/root/realms/OpenData/userinfo? is : {“subname”:“XXXXXXXXXXXX”} that is my login in the authorisation login page below:
Also I have different code from your version, I try to put in this version your suggestions, also I think that: dbg_obj_princ (‘VAL.DBA.oauth_id_token (’, id, id_token, token, options ‘)’) must be dbg_obj_princ (‘VAL.DBA.oauth_id_token (’, id, id_token, token, options, ‘)’) [comma after options]
-- dbg_obj_princ ('VAL.DBA.oauth_id_token (', id, id_token, token, ')');
dbg_obj_princ ('VAL.DBA.oauth_id_token (', id, id_token, token, options, ')');
declare N integer;
declare tmp, params, data, jwks any;
declare nonce, returned_nonce, webid varchar;
serviceId := null;
if (not isnull (id_token))
{
jwks := VAL.DBA.oauth_id_token_keys (service, options);
if (isnull (jwks))
goto _userinfo;
data := OAUTH2.DBA.id_token_verify (id_token, jwks);
dbg_obj_princ(current_proc_name(), ', data: ', data);
if (not isnull (data))
.....
}
What you mean with “Virtuoso console output?” In Monitor->Log Viewer have no trace of the debug… You mean [#] isql localhost:1111 dba dba -D ?? How can I set the deug ?
Thanks.
Regards.
Yes re: dbg_obj_princ and the missing comma. Sorry about the typo.
You need to start Virtuoso with the -f option to see the output from dbg_obj_princ and dbg_printf etc.
It looks like /openam/oauth2/realms/root/realms/OpenData/userinfo is returning a JSON object which contains a ‘subname’ claim/property. However the OIDC spec stipulates that it must contain a ‘sub’ claim. VAL expects to find a ‘sub’ claim.
In procedure VAL.DBA.oauth_id_token
_skipUserinfo:;
webid := get_keyword ('webid', data);
if (isnull (webid))
webid := get_keyword ('sub', data);
You could maybe try changing the above to
_skipUserinfo:;
webid := get_keyword ('webid', data);
if (isnull (webid))
webid := get_keyword ('subname', data);
Hi @cblakeley,
I expose your osservation to my Openam team, they will investigate !
Hi @cblakeley in the mean time I find this page of Forgerock:
https://backstage.forgerock.com/docs/idcloud-am/latest/oidc1-guide/rest-api-oidc-userinfo-endpoint.html
Where in the GET there is a reference to subname, ex:
$ curl
–request GET
–header “Authorization: Bearer U-Wjlv-w1jtpuBVWUGFV6PwI_nE”
“https:///am/oauth2/realms/root/realms/alpha/userinfo”
{
“given_name”:“Demo First Name”,
“family_name”:“Demo Last Name”,
“name”:“demo”,
“sub”:“(usr!demo)”,
“subname”:“id=demo,ou=user,o=root,ou=services,dc=openam,dc=forgerock,dc=org”
}
Hi @cblakeley,
Openam fix the issue but now I am getting this error:
“UD055 22023 Can’t write to an user defined type column”
The userinfo now returns:
{“sub”:“-Alfanumeric code-”,“given_name”:“-MyName-”,“family_name”:“-MyFamilyName-”,“name”:" -Alfanumeric code-“,“subname”:” -Alfanumeric code-"}
Also can you please give me instruction for debug mode with the commercial edition because I start the virtuoso with an sh command: virtuoso-start.sh.
Thanks.
Regards.
Hi @cblakeley finally, debugging, I found the error, this is an ex. of the query:
insert into OAUTH.DBA.CLI_SESSIONS (
CS_KEY,
CS_SECRET,
CS_SERVICE,
CS_SERVICE_ID,
CS_SID,
CS_TOKEN_TYPE,
CS_TOKEN,
CS_ID_TOKEN,
CS_REFRESH_TOKEN,
CS_EXPIRE_TIME,
CS_USER_DATA,
CS_SCOPE,
CS_DATE,
CS_CODE_CHALLANGE,
CS_CODE_CHALLANGE_METHOD,
CS_DPOP_KEYTYPE,
CS_DPOP_KEYNAME,
CS_DPOP_KEYVALUE)
VALUES (
'xxxxxx',
'xxxxx',
'Service',
'CFX',
'08ffec23c0f10b3d876c1638d5c43077',
'Bearer',
'ISmWKs01PnWgbLNzDEbHxqWmNQA',
'<TOKEN_GIVEN>',
null,
2022-10-11,
'test',
'basic',
2022-10-11,
null,
null,
null,
null,
null);
I think the problem is:
CS_ID_TOKEN TYPE INSTANCE ???
@EdgarCap In speaking with @cblakeley he indicates having seen a similar error to the one you reported before, for which a fix to prevent its occurrence was made in this 2.2.4_git29
val_dav.vad.zip (747.7 KB) VAL VAD, which you can upgrade to and retest.
Ok, many thanks.
I will install this new version.
Regards.
Hi @hwilliams and @cblakeley , installing the package, in the new release is missing the fix:
-- scope request parameter is not required for authorization code grant
-- if (not isnull (scope))
-- params := params || sprintf ('&scope=%U', scope);
In the PROCEDURE: VAL.DBA.oauth_token
Now, all is ok, except the part of the code before !
Thanks.
Regards.