Closed tharakawijekoon closed 3 weeks ago
Current fix will only work when groups claim is requested in the login application. However it shouldn't work like that. Federated user is assigned the role and role has the permissions to grant the requested scopes. Apps shouldn't be requesting groups in order to retrieve the roles associated to the user. Here the actual problem is that, IDP mapped attributes are not getting mapped in the provisioned user object correctly.
(Check the internal for further details)
Steps to reproduce the issue:
https://localhost:9443/commonauth
).https://wso2.org/claims/groups
as a SP requested claims.groups
claim to openid
OIDC scope.localgroup
(not a role).Internal/localrole
) and assign the required permissions.scope=openid
.internal_user_mgt_list internal_user_mgt_update
scopes. Perform the login and obtain the authorization code. Send the token request and see whether scopes are returned (If the scopes are checked during login, you will be prompted for consent. Can verify with that as well.)https://wso2.org/claims/groups
as a SP requested claims. Try the login and now the scopes will be returned.This does not need a master fix. It is handled by https://github.com/wso2/carbon-identity-framework/pull/5396 The above PR solves the issue in the default pack. But need to fix this in legacy mode
This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!
Describe the issue: OIDC federated users are not able to get scopes even though proper role mapping configurations are present and the federated IDP returns mapped roles.
How to reproduce:
Configure an OIDC federated IDP with the Identity server so that it returns "testrole" in the ID token for the groups claim.
Configure IDP claim mapping and set the role claim to groups as shown below.
Add Internal/localrole to the Identity server and map the "testrole" to the local role as shown below.
Register a oauth service provider and set up the federated IDP with it.
Login to the federated IDP with requested scopes -"internal_login internal_user_mgt_list internal_user_mgt_update"(make sure the Internal/localrole has the permissions to get these scopes)
The requested scopes will not be returned.(If there is any doubt on the claim mapping or role mapping configurations enable silent JIT provisioning and verifiy the role is provisioned to the user, however do not enable "Assert identity using mapped local subject identifier" option)
Expected behavior:
Federated user should be able to get the requests scopes provided that the role mappings are configured correctly and the required roles are sent from the federated IDP.
The JDBCPermissionBasedInternalScopeValidator[1] does not seem to be tested for this scenario, we compare the remote claim with "groups"[2] but the remote claim comes as "http://wso2.org/claims/groups"(IS-6.0.0) or "http://wso2.org/claims/role"(IS-5.10.0) so the groups are never returned.
Even if the roles are returned, the mapping with Internal roles scenario has not been tested, so the roles are not detected properly[3]
[1]https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/1511/files [2]https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/2aed8dc9828178bd1aa3abcd1f3a4439c0e6db50/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/validators/JDBCPermissionBasedInternalScopeValidator.java#L375C23-L375C23 [3]https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/2aed8dc9828178bd1aa3abcd1f3a4439c0e6db50/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/validators/JDBCPermissionBasedInternalScopeValidator.java#L306
Environment information :
Optional Fields
Related issues: https://github.com/wso2/product-is/issues/10527