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

Feature: allow client-sso-user to switch to sso-users only when using P4V #3

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jerem991
Copy link

@jerem991 jerem991 commented Aug 7, 2024

Hello,

This is a MR request that allows switching a user from the client-sso-users group (non-interactive flow) to the sso-users group (interactive flow) when using P4V (which is intended for interactive use).

Due to our synchronization requirements, we cannot solely use the interactive flow (sso-users) for our user accounts. Over the weekend, we sync data using libraries through WAM to log in silently to Perforce, ensuring everything is ready for work on Monday morning. We aim to avoid any Web SSO authentication pop-ups that could disrupt this process.

The problem arises when a user is classified as a client-sso-user and attempts to log in using P4V. P4V prompts for the user’s password and does not execute the P4LOGINSSO routine. Therefore, the P4V app should automatically be considered as part of the interactive flow (Web SSO) since automation is not feasible in this context.

@jerem991 jerem991 changed the title Feature: allow user SSO to combine non interactive flow and interactive flow only to P4V Feature: allow client-sso-user to switch to sso-users only when using P4V Aug 7, 2024
@p4-nathan
Copy link
Collaborator

Hello Jérémie, thank you for the contribution. I will discuss this with product management and we will try to devise a more general solution to the problem of users that need to authenticate in different ways. While examining the clientprog is one way, hard-coding to "P4V" might be too restrictive to work for everyone. I also dislike leaving it up to the client to control this as an attacker could leverage this knowledge to find a way around web-based SSO authentication. Sure, it's not really any easier to hack the usual auth mechanism, but I prefer keeping the control entirely in the server rather than the client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants