Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Role based outbound provisioning not triggered via assigning roles/groups through console app #11394

Open
tharindu-b-hewage opened this issue Mar 5, 2021 · 4 comments
Assignees
Labels
console Console portal application and product API development Type/Bug

Comments

@tharindu-b-hewage
Copy link
Contributor

Describe the issue:
Configure role-based outbound provisioning and simulate the flow by assigning outbound provisioning role to a user in the management console. It works.

But assigning the role via console does not trigger provisioning.

The same happens for assigning a group via the console app.

How to reproduce:
Config role-based outbound provisioning.

Assign the provisioning role to a user via mgt console, it works.

Assign as a role to a user via console app, it does not trigger provisioning.

Assign as a group to a user via console app, it does not trigger provisioning.

Expected behavior:
When a role or group assigned to the user, that user should be provisioned if the assigned role/group is the provisioning role.

@tharindu-b-hewage tharindu-b-hewage added this to the 5.12.0-checkpoint-2 milestone Mar 5, 2021
@nilasini nilasini added the console Console portal application and product API development label Apr 4, 2022
@nilasini nilasini modified the milestones: 5.12.0-checkpoint-2, 5.13.0 Apr 4, 2022
@madurangasiriwardena madurangasiriwardena removed this from the 5.13.0 milestone Jul 31, 2023
@ShehanDinuka
Copy link
Contributor

ShehanDinuka commented Aug 22, 2024

Hi Team,

This issue is reproducible in IS 7.0.0 as well. From the console, only roles can be assigned, not groups, which should also be configurable. When a role is assigned from the console, it is saved without the "Internal" domain in the IDP outboundProvisioningRoles configuration. Due to the missing "Internal" domain, when the canUserBeProvisioned()[1] method checks if the user is allowed to be provisioned, it incorrectly determines that the user does not have the provisioning role because of the missing "Internal" domain prefix.

Using the following request should resolve the issue.

curl --location --request PUT 'https://localhost:9443/t/carbon.super/api/server/v1/identity-providers/<idp-id>/roles' \
--header 'Accept: application/json' \
--header 'Referer;' \
--header 'Authorization: Basic YWRtaW46YWRtaW4=' \
--header 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36' \
--header 'Content-Type: application/json' \
--data '{
    "mappings": [],
    "outboundProvisioningRoles": [
        "Internal/test1"
    ]
}'

@sadilchamishka
Copy link
Contributor

sadilchamishka commented Aug 26, 2024

Hi @ShehanDinuka

Even the role can be added via the API call, the role based outbound provisioning will be triggered when role assignment from the management console. When role assignment from the console app or via scim2/Roles API will not work as raised in this issue.

As management console is not recommended for the IS 7.0 and it is running in legacy mode with less features, we will have improve this feature properly working with REST APIs.

We are not promoting the Internal\ prefix for the roles. If we are passing that in the API payload it will make confusions.
I have tested without that prefix with only the role name, and the role based outbound provisioning is working fine. (The setup has the patches related to the backend fixes)

There are few other bugs around this feature which required to be fixed.

  1. Trying to delete a group will not remove the outbound provisioned group due to below issue.
  1. UI bug in provisioning connector information update.
  1. UI inconsistency of displaying roles to assign for role based outbound provisioning.
  1. UI issue of dropdown menu for selecting roles for role based outbound provisioning.

Thanks,
Sadil

@sadilchamishka
Copy link
Contributor

Hi Team,

This issue is reproducible in IS 7.0.0 as well. From the console, only roles can be assigned, not groups, which should also be configurable. When a role is assigned from the console, it is saved without the "Internal" domain in the IDP outboundProvisioningRoles configuration. Due to the missing "Internal" domain, when the canUserBeProvisioned()[1] method checks if the user is allowed to be provisioned, it incorrectly determines that the user does not have the provisioning role because of the missing "Internal" domain prefix.

Using the following request should resolve the issue.

curl --location --request PUT 'https://localhost:9443/t/carbon.super/api/server/v1/identity-providers/<idp-id>/roles' \
--header 'Accept: application/json' \
--header 'Referer;' \
--header 'Authorization: Basic YWRtaW46YWRtaW4=' \
--header 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36' \
--header 'Content-Type: application/json' \
--data '{
    "mappings": [],
    "outboundProvisioningRoles": [
        "Internal/test1"
    ]
}'

Hi @ShehanDinuka

The referenced code line [1] is only executed when assigning a role to the user via the management console. Assigning a user to the role will not engaged in this flow. The REST APIs supports to assign a user to a role. Hence this flow is not engaged during the provision flow. Hence raised this PR, which triggers outbound provisioning when role updates [2].

[1] - https://github.com/wso2/carbon-identity-framework/blob/e4e583f08a52c7ad7f72fddaf6fbcd3a867a3601/components/provisioning/org.wso2.carbon.identity.provisioning/src/main/java/org/wso2/carbon/identity/provisioning/OutboundProvisioningManager.java#L560
[2] - wso2/carbon-identity-framework#5893

Thanks,
Sadil

@sadilchamishka
Copy link
Contributor

sadilchamishka commented Sep 1, 2024

Testing effort

1. Outbound User provisioning.

  • 1.1 - Create user -> User get provisioned.
  • 1.2 - Update user claims (both identity & non identity claims) -> The claims get propagated to provisioned user.
  • 1.3 - Delete user -> User get de provisioned.
  • 1.4 - Self signup -> User get provisioned.

2. Outbound Group provisioning.

  • 2.1 - Create group -> Group get provisioned.
  • 2.2 - Delete group -> Group get de provisioned.

3. Complex user group creations while outbound provisioning.

  • 3.1 - Create user added to multiple groups -> User get provisioned and assigned for corresponding provisioned groups.
  • 3.2 - Create group with multiple users -> Group get provisioned and users get assigned for the provisioned group.
  • 3.3 - Invite user with groups -> User get provisioned with provisioned groups assigned.

(When set of provisioned groups not exist when creating user and whe set of users not exists when provisioning groups lead to fail the provisioning process. It was fixed to provision with available user or groups)

4. Assign users to groups.

  • 4.1 - Add user to group -> User get assigned for the provisioned group.
  • 4.2 - Remove user from group -> User get removed for the provisioned group.

5. Outbound provisioning when role management

  • 5.1 - Create user -> User not get provisioned.
  • 5.1 - Create group -> Group get provisioned.
  • 5.3 - Assign user to the provisioning role or group -> The user get provisioned.
  • 5.4 - Remove the assignment for the role or group -> User get de provisioned.
  • 5.5 - Delete the user -> User get de provisioned.
  • 5.6 - Create user with required group -> User get provisioned but not assigned for the group
  • 5.7 - Assign user to required group -> User get provisioned but not assigned for the group

The 5.6 & 5.7 are partially happening due to the issue raised here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
console Console portal application and product API development Type/Bug
Projects
None yet
Development

No branches or pull requests

5 participants