Enhance SSO User Role Assignment Configuration

[steveliem]

Problem Statement

Currently, when deploying CISO Assistant on OpenShift with Keycloak configured for Single Sign-On (SSO), the application automatically assigns the admin role to new users upon their first SSO login. This behavior poses a security risk, as any user with SSO access can inadvertently gain administrative privileges. Conversely, if an admin pre-creates a user in CISO Assistant and assigns them to a specific group, the user receives the correct permissions upon first SSO login. However, this manual process is not scalable and lacks flexibility.

Expected Behavior

1. As an administrator, navigate to the 'Settings' page under the 'Extra' menu.
2. Enable SSO and configure the Identity Provider (IdP) details.
3. Access a new section titled 'SSO User Role Assignment' within the SSO configuration settings.
4. In this section, specify the default group or role to be assigned to users upon their first SSO login.
5. Choose from the following options:
   • Assign users to a default group configured by the admin.
   • Require admin approval before granting access, with users placed in a pending state until approved.
6. Save the configuration.
7. Upon first SSO login, users are either assigned to the specified default group or informed that their access is pending admin approval.
8. Administrators can view and manage pending user requests through a dedicated dashboard, approving or denying access and assigning appropriate groups as necessary.

Mock

Not applicable.

Additional Context

Implementing this feature enhances security by preventing unauthorized users from gaining administrative access through SSO. It also streamlines user management by allowing administrators to define default roles for new SSO users and manage access approvals efficiently. This approach aligns with Role-Based Access Control (RBAC) best practices, ensuring that users have appropriate permissions based on their roles.

[eric-intuitem]

Thanks for the report; we’ll look into it promptly. Don't hesitate to contact us on Discord.

[ab-smith]

Hello @steveliem and thank you for reporting this,
The current setup doesn’t support auto-enrollement for this specific reason. Did you use the base code as-is? Any specific setup on your keycloak? Or you just followed up the instructions here: https://intuitem.gitbook.io/ciso-assistant/features-highlight/sso/keycloak
Regards,

[steveliem]

Hello @ab-smith,

Thank you for your response.

To answer your questions:

1. I used the Helm chart provided for deploying the CISO Assistant application.
2. I followed the instructions exactly as outlined in the documentation link you referenced: Keycloak SSO Integration.
3. In my environment, Keycloak is provisioned as a PaaS in a production-grade scenario.

Let me know if there's anything further I should verify or adjust in the setup.

[ab-smith]

thank you @steveliem , one more thing: are you sure that you are not using the same email address as the initial one on CISO Assistant and assumed it was auto-enrolled?
we can chat over this on Discord :)

[steveliem]

Hi @ab-smith,

Thank you for the follow-up! Here's what I did to clarify and test the behavior:

1. I performed a helm uninstall and removed the PVC where the database was persisted to ensure no residual data or configuration remained.
2. I did a fresh helm install and reconfigured SSO with Keycloak from scratch.
3. When attempting an SSO login initially, I received the message: "User is not permitted. Please contact the administrator."
4. After creating the user in CISO Assistant without assigning any group and retrying the SSO login, the login succeeded with restricted access—limited to the analysis page and domain page.
5. Subsequently, logging in as the admin, I was able to assign the appropriate group to the user and manage access as expected.

Upon reflection, it seems the original issue stemmed from the fact that the email in question had been previously enrolled as the admin user. Even after deleting the admin user, the application appeared to retain a configuration or reference recognizing that email as an admin. This behavior created the initial confusion, but starting fresh with a clean setup resolved the problem entirely.

So, to summarize, the current implementation works as expected when starting fresh. Thank you for helping me clarify this process!

P.s. I'm having issues with my Discord user. Hopefully it's not an issue for you communicating this way. :-)

[ab-smith]

Glad to hear that. Thank you for your reactivity and input, regardless of the channel. We really appreciate your feedback, as these topics are a top priority for our design and implementation.

The user management is persistent at the db level indeed, and access is challenged for each request actually, could be some caching at the browser level.

I'll close this ticket, and I'll create an enhancement one to keep track of the requests regarding the auto-enrollment topic that we will tackle middle of next year.

In the meantime, I'll take a look at the helm chart topic you've raised on the other repo, as this one is probably more impactful in the short term.

Warm regards,