Incorrect scopes persisted during manual registration of OIDC client #1282

ossdhaval · 2022-05-04T07:51:31Z

Describe the bug
During manual registration of OIDC client through jans-cli, the scopes that are persisted in MySQL table are not in Dn format.
What is stored : {"v": ["email", "openid", "profile"]}
What should be stored : {"v": ["inum=C4F7,ou=scopes,o=jans", "inum=C4F6,ou=scopes,o=jans", ...]}

To Reproduce
Steps to reproduce the behavior:

Use config-cli on janssen server
Select option for open id connect clients ( option 16)
Then select option for registering new client
Provide all inputs as mentioned below:

displayName: <name-of-choice>
application Type: web
includeClaimsInIdToken  [false]: 
Populate optional fields? y
clientSecret: <secret-of-your-choice>
subjectType: public
tokenEndpointAuthMethod: client_secret_basic
redirectUris: https://test.apache.rp.io/callback
scopes: email_,openid_,profile
responseTypes: code
grantTypes: authorization_code

check the schema JSON that is being used for client registration, mine was

{
  "dn": null,
  "inum": null,
  "displayName": "myrp",
  "clientSecret": "mysecretpw",
  "frontChannelLogoutUri": null,
  "frontChannelLogoutSessionRequired": null,
  "registrationAccessToken": null,
  "clientIdIssuedAt": null,
  "clientSecretExpiresAt": null,
  "redirectUris": [
    "https://test.apache.rp.io/callback"
  ],
  "claimRedirectUris": null,
  "responseTypes": [
    "code"
  ],
  "grantTypes": [
    "authorization_code"
  ],
  "applicationType": "web",
  "contacts": null,
  "clientName": null,
  "idTokenTokenBindingCnf": null,
  "logoUri": null,
  "clientUri": null,
  "policyUri": null,
  "tosUri": null,
  "jwksUri": null,
  "jwks": null,
  "sectorIdentifierUri": null,
  "subjectType": "public",
  "idTokenSignedResponseAlg": null,
  "idTokenEncryptedResponseAlg": null,
  "idTokenEncryptedResponseEnc": null,
  "userInfoSignedResponseAlg": null,
  "userInfoEncryptedResponseAlg": null,
  "userInfoEncryptedResponseEnc": null,
  "requestObjectSigningAlg": null,
  "requestObjectEncryptionAlg": null,
  "requestObjectEncryptionEnc": null,
  "tokenEndpointAuthMethod": "client_secret_basic",
  "tokenEndpointAuthSigningAlg": null,
  "defaultMaxAge": null,
  "requireAuthTime": null,
  "defaultAcrValues": null,
  "initiateLoginUri": null,
  "postLogoutRedirectUris": null,
  "requestUris": null,
  "scopes": [
    "email",
    "openid",
    "profile"
  ],
  "claims": null,
  "trustedClient": false,
  "lastAccessTime": null,
  "lastLogonTime": null,
  "persistClientAuthorizations": null,
  "includeClaimsInIdToken": false,
  "refreshTokenLifetime": null,
  "accessTokenLifetime": null,
  "customAttributes": null,
  "customObjectClasses": null,
  "rptAsJwt": null,
  "accessTokenAsJwt": null,
  "accessTokenSigningAlg": null,
  "disabled": false,
  "authorizedOrigins": null,
  "softwareId": null,
  "softwareVersion": null,
  "softwareStatement": null,
  "attributes": null,
  "backchannelTokenDeliveryMode": null,
  "backchannelClientNotificationEndpoint": null,
  "backchannelAuthenticationRequestSigningAlg": null,
  "backchannelUserCodeParameter": null,
  "expirationDate": null,
  "deletable": false,
  "jansId": null,
  "description": null
}

as shown above, the scopes are not sent in Dn format but rather in simple format.

Go ahead and let CLI create client by typing y on prompt.
Client registration is successful and JSON response is received back. As below

{
  "dn": "inum=68281b57-f108-4fec-9ebe-e51f42b6808c,ou=clients,o=jans",
  "inum": "68281b57-f108-4fec-9ebe-e51f42b6808c",
  "displayName": "myrp",
  "clientSecret": "mysecretpw",
  "frontChannelLogoutUri": null,
  "frontChannelLogoutSessionRequired": false,
  "registrationAccessToken": null,
  "clientIdIssuedAt": null,
  "clientSecretExpiresAt": null,
  "redirectUris": [
    "https://test.apache.rp.io/callback"
  ],mysecretpw
  "claimRedirectUris": null,
  "responseTypes": [
    "code"
  ],
  "grantTypes": [
    "authorization_code"
  ],
  "applicationType": "web",
  "contacts": null,
  "clientName": "myrp",
  "idTokenTokenBindingCnf": null,
  "logoUri": null,
  "clientUri": null,
  "policyUri": null,
  "tosUri": null,
  "jwksUri": null,
  "jwks": null,
  "sectorIdentifierUri": null,
  "subjectType": "public",
  "idTokenSignedResponseAlg": null,
  "idTokenEncryptedResponseAlg": null,
  "idTokenEncryptedResponseEnc": null,
  "userInfoSignedResponseAlg": null,
  "userInfoEncryptedResponseAlg": null,
  "userInfoEncryptedResponseEnc": null,
  "requestObjectSigningAlg": null,
  "requestObjectEncryptionAlg": null,
  "requestObjectEncryptionEnc": null,
  "tokenEndpointAuthMethod": "client_secret_basic",
  "tokenEndpointAuthSigningAlg": null,
  "defaultMaxAge": null,
  "requireAuthTime": false,
  "defaultAcrValues": null,
  "initiateLoginUri": null,
  "postLogoutRedirectUris": null,
  "requestUris": null,
  "scopes": [
    "email",
    "openid",
    "profile"
  ],
  "claims": null,
  "trustedClient": false,
  "lastAccessTime": null,
  "lastLogonTime": null,
  "persistClientAuthorizations": false,
  "includeClaimsInIdToken": false,
  "refreshTokenLifetime": null,
  "accessTokenLifetime": null,
  "customAttributes": [],
  "customObjectClasses": null,
  "rptAsJwt": false,
  "accessTokenAsJwt": false,
  "accessTokenSigningAlg": null,
  "disabled": false,
  "authorizedOrigins": null,
  "softwareId": null,
  "softwareVersion": null,
  "softwareStatement": null,
  "attributes": {
    "tlsClientAuthSubjectDn": null,
    "runIntrospectionScriptBeforeAccessTokenAsJwtCreationAndIncludeClaims": false,
    "keepClientAuthorizationAfterExpiration": false,
    "allowSpontaneousScopes": false,
    "spontaneousScopes": null,
    "spontaneousScopeScriptDns": null,
    "backchannelLogoutUri": null,
    "backchannelLogoutSessionRequired": false,
    "additionalAudience": null,
    "postAuthnScripts": null,
    "consentGatheringScripts": null,
    "introspectionScripts": null,
    "rptClaimsScripts": null
  },
  "backchannelTokenDeliveryMode": null,
  "backchannelClientNotificationEndpoint": null,
  "backchannelAuthenticationRequestSigningAlg": null,
  "backchannelUserCodeParameter": null,
  "expirationDate": null,
  "deletable": false,
  "jansId": null,
  "description": null{
  "dn": "inum=68281b57-f108-4fec-9ebe-e51f42b6808c,ou=clients,o=jans",
  "inum": "68281b57-f108-4fec-9ebe-e51f42b6808c",
  "displayName": "myrp",
  "clientSecret": "mysecretpw",
  "frontChannelLogoutUri": null,
  "frontChannelLogoutSessionRequired": false,
  "registrationAccessToken": null,
  "clientIdIssuedAt": null,
  "clientSecretExpiresAt": null,
  "redirectUris": [
    "https://test.apache.rp.io/callback"
  ],mysecretpw
  "claimRedirectUris": null,
  "responseTypes": [
    "code"
  ],
  "grantTypes": [
    "authorization_code"
  ],
  "applicationType": "web",
  "contacts": null,
  "clientName": "myrp",
  "idTokenTokenBindingCnf": null,
  "logoUri": null,
  "clientUri": null,
  "policyUri": null,
  "tosUri": null,
  "jwksUri": null,
  "jwks": null,
  "sectorIdentifierUri": null,
  "subjectType": "public",
  "idTokenSignedResponseAlg": null,
  "idTokenEncryptedResponseAlg": null,
  "idTokenEncryptedResponseEnc": null,
  "userInfoSignedResponseAlg": null,
  "userInfoEncryptedResponseAlg": null,
  "userInfoEncryptedResponseEnc": null,
  "requestObjectSigningAlg": null,
  "requestObjectEncryptionAlg": null,
  "requestObjectEncryptionEnc": null,
  "tokenEndpointAuthMethod": "client_secret_basic",
  "tokenEndpointAuthSigningAlg": null,
  "defaultMaxAge": null,
  "requireAuthTime": false,
  "defaultAcrValues": null,
  "initiateLoginUri": null,
  "postLogoutRedirectUris": null,
  "requestUris": null,
  "scopes": [
    "email",
    "openid",
    "profile"
  ],
  "claims": null,
  "trustedClient": false,
  "lastAccessTime": null,
  "lastLogonTime": null,
  "persistClientAuthorizations": false,
  "includeClaimsInIdToken": false,
  "refreshTokenLifetime": null,
  "accessTokenLifetime": null,
  "customAttributes": [],
  "customObjectClasses": null,
  "rptAsJwt": false,
  "accessTokenAsJwt": false,
  "accessTokenSigningAlg": null,
  "disabled": false,
  "authorizedOrigins": null,
  "softwareId": null,
  "softwareVersion": null,
  "softwareStatement": null,
  "attributes": {
    "tlsClientAuthSubjectDn": null,
    "runIntrospectionScriptBeforeAccessTokenAsJwtCreationAndIncludeClaims": false,
    "keepClientAuthorizationAfterExpiration": false,
    "allowSpontaneousScopes": false,
    "spontaneousScopes": null,
    "spontaneousScopeScriptDns": null,
    "backchannelLogoutUri": null,
    "backchannelLogoutSessionRequired": false,
    "additionalAudience": null,
    "postAuthnScripts": null,
    "consentGatheringScripts": null,
    "introspectionScripts": null,
    "rptClaimsScripts": null
  },
  "backchannelTokenDeliveryMode": null,
  "backchannelClientNotificationEndpoint": null,
  "backchannelAuthenticationRequestSigningAlg": null,
  "backchannelUserCodeParameter": null,
  "expirationDate": null,
  "deletable": false,
  "jansId": null,
  "description": null
}
}

Now if you try to use this client for authentication for any user, it doesn't work. jans-auth.log has this error.

(ClientService.java:140) - Found 1 entries for client id = 68281b57-f108-4fec-9ebe-e51f42b6808c
2022-05-02 11:42:00,458 TRACE [qtp982757413-17] 98ae84c5-b630-4282-b31c-461482dfd44b [io.jans.as.server.service.ScopeService] (ScopeService.java:144) - Failed to find entry: 'email'
io.jans.orm.exception.EntryPersistenceException: Failed to find entry: 'email'

Upon checking MySql table using following query, It shows that scopes are not in Dn format.

SELECT jansScope FROM jansdb.jansClnt where doc_id = "68281b57-f108-4fec-9ebe-e51f42b6808c";

Expected behavior

Scopes should be persisted in Dn format
If config-api expects Dn formatted input from jans-cli then Swagger doc needs to be fixed as it is currently showing simple format
Need to understand why jans-auth.log logs this issue as TRACE and not as ERROR. This creates a hidden failure which is not logged at all unless log level is changed to TRACE.

Screenshots
config-api swagger showing scopes accepted in non-Dn format

Desktop (please complete the following information):

janssen installed on a VM with MySql backend

The text was updated successfully, but these errors were encountered:

devrimyatar · 2022-05-04T10:17:41Z

This is not an issue. User should enter scopes in dn format. See below.

vokoscreenNG-2022-05-04_13-16-29.mp4

pujavs · 2022-05-04T13:36:13Z

At present config-api acts as a pass through and hence expects the scopes as dn, it takes the scope and saves them as it.
example:
["inum=C4F7,ou=scopes,o=jans", "inum=C4F6,ou=scopes,o=jans", ...]
and not
["email", "openid", "profile"]

Checking with Yuriy regarding the expected behaviour on Scopes should be persisted in Dn format.

ossdhaval · 2022-05-04T14:17:55Z

Adding @yuriyz as Puja mentioned above.

Having users to add inum=C4F7,ou=scopes,o=jans for scope email for example is not user friendly. Because everytime use has to look-up the correct Dn for the scope. I understand that adding a new client will not be a frequent operation, but we also use same Dn based values when we get info about a client.

Agreed that CLI may not be able to translate email to inum=C4F7,ou=scopes,o=jans on its own. But can't we have config-api do this translation?

ossdhaval · 2022-05-04T14:24:56Z

@yurem for comments on above.

yuriyz · 2022-05-04T14:30:53Z

Yes, I agree. We just discussed it with @pujavs .

config-api can check whether scope is in DN format :

if yes -> pass it forward as it does it already
if no -> look up scope by name against db. If scope is found -> use it. If not found -> error.

pujavs · 2022-05-04T14:32:46Z

thanks @yuriyz for your inputs, working on it

pujavs · 2022-05-05T12:07:18Z

Implemented check as suggested by @yuriyz as follows;

config-api can check whether scope is in DN format :

if DN format yes -> pass it forward as it does it already
if not in DN format -> look up scope by name against db. If scope is found -> use it. If not found -> error.

Testing:

Case#1: Valid scopes: If scope is provided in DN format it accepts as is else fetches DN from DB

Case#2: Invalid scope name: Will throw exception with details of invalid scope.
Example: "Invalid scope in request -> [abc, xyz]"

Case#3: Invalid DN: Will throw exception with details of invalid scope.

pujavs · 2022-05-05T12:08:19Z

Related PR 1293

pujavs · 2022-05-05T14:35:31Z

@ossdhaval, change has been merged, request you to please verify

ossdhaval · 2022-05-05T14:57:54Z

Thanks @pujavs
I'll validate this from jans-cli. Does jans-cli need any changes to accommodate this? @mbaser

devrimyatar · 2022-05-09T14:33:42Z

There is no need any change in CLI.
@pujavs I am getting error

devrimyatar · 2022-05-09T19:47:53Z

When we use id of scope, config-api registers it's dn.

vokoscreenNG-2022-05-09_22-45-29.mp4

Closing the issue

ossdhaval assigned devrimyatar and pujavs May 4, 2022

pujavs mentioned this issue May 5, 2022

feat(jans-config-api): added scope DN validation while client creation #1293

Merged

pujavs assigned ossdhaval May 5, 2022

devrimyatar closed this as completed May 9, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Incorrect scopes persisted during manual registration of OIDC client #1282

Incorrect scopes persisted during manual registration of OIDC client #1282

ossdhaval commented May 4, 2022

devrimyatar commented May 4, 2022

pujavs commented May 4, 2022 •

edited

Loading

ossdhaval commented May 4, 2022 •

edited

Loading

ossdhaval commented May 4, 2022

yuriyz commented May 4, 2022

pujavs commented May 4, 2022

pujavs commented May 5, 2022 •

edited

Loading

pujavs commented May 5, 2022

pujavs commented May 5, 2022

ossdhaval commented May 5, 2022

devrimyatar commented May 9, 2022

devrimyatar commented May 9, 2022

Incorrect scopes persisted during manual registration of OIDC client #1282

Incorrect scopes persisted during manual registration of OIDC client #1282

Comments

ossdhaval commented May 4, 2022

devrimyatar commented May 4, 2022

pujavs commented May 4, 2022 • edited Loading

ossdhaval commented May 4, 2022 • edited Loading

ossdhaval commented May 4, 2022

yuriyz commented May 4, 2022

pujavs commented May 4, 2022

pujavs commented May 5, 2022 • edited Loading

Implemented check as suggested by @yuriyz as follows;

Testing:

pujavs commented May 5, 2022

pujavs commented May 5, 2022

ossdhaval commented May 5, 2022

devrimyatar commented May 9, 2022

devrimyatar commented May 9, 2022

pujavs commented May 4, 2022 •

edited

Loading

ossdhaval commented May 4, 2022 •

edited

Loading

pujavs commented May 5, 2022 •

edited

Loading