P4 user and group provisioning

The advantage of P4 user and group provisioning is that users you create in your cloud service provider (such as Okta, Azure, OneLogin) can automatically be provisioned as P4 users. In addition, these users can authenticate with P4 Authentication Service.

This functionality is an implementation of the System for Cross-domain Identity Management (SCIM).

Provisioning is independent

Although we encourage customers using P4 Authentication Service to also take advantage of this service for user and group provisioning, it is optional and independent. That means:

  • You can use P4 Authentication Service with or without using this service for user and group provisioning.

  • You can use this service for user and group provisioning with or without using P4 Authentication Service.

Limitations

This implementation of SCIM does not support deprovisioning.

Any attempt by the cloud service provider to rename a user is rejected with a “mutability” error. Although the ALLOW_USER_RENAME setting can be set to true, renaming a user in P4 can have adverse effects.

Okta permits renaming a user, and removing the renamed user from Okta, but the renamed user remains active in P4 Authentication Service.

Configuring users and groups

Prerequisites

Make sure that P4 Authentication Service is reachable by your cloud service provider so that it can connect to the /scim/v2 endpoint. Restrict network access to trusted systems and users that require access to P4 Authentication Service. Protect access to the /scim/v2 endpoint by using the unique BEARER_TOKEN configured for your P4 Authentication Service installation.

Configure P4TRUST and P4TICKETS

  1. On the P4 Authentication Service system, use the p4 user account with the super access level to run p4 trust and p4 login See p4 trust and p4 login in P4 CLI Reference.

  2. Make sure the ticket is a long-lived one. To create a ticket that does not expire after the default of 12 hours, see Ticket-based authentication in P4 Server Administration Documentation.

  3. Make sure that the .p4tickets and .p4trust files are readable by the system user that is running the P4 Authentication Service process. This system user is probably the perforce user if you installed P4 Authentication Service using a package.

  4. Set P4TICKETS and P4TRUST in the P4 Authentication Service .env file to reference the .p4tickets and .p4trust files you created in Step 1.

Configuration steps

  1. In your cloud service provider:

    1. Make sure that you have P4 groups. The most basic arrangement is a group for P4 administrators and a group of regular users, but you can have any number of groups and control access in many ways. See Setting protections with p4 protect in P4 Server Administration Documentation.

    2. Create P4 users and assign them to the appropriate P4 groups.

    3. Assign passwords to the users, and best practice is to tell the users to change their password upon login.

  2. Use the P4 Authentication Service configuration script to configure the service. For more information, see Configuring.

    Starting with P4 Authentication Service 2026.1, the configuration script automatically generates random values for BEARER_TOKEN and SESSION_SECRET if they are not already defined.

    Do not use default or example values for these settings.

    Existing values are preserved during upgrades. Running an upgrade does not automatically regenerate or replace an existing BEARER_TOKEN or SESSION_SECRET.

  3. In the form for configuring the cloud service provider's provisioning feature, provide:

    1. The URL of the P4 Authentication Service service with /scim/v2 appended as a suffix. For example: https://has.example.com/scim/v2

    2. The BEARER_TOKEN configured for P4 Authentication Service.

You can now create P4 groups and users with the provisioning service of your cloud service provider.

This provisioning service follows the standard of System for Cross-domain Identity Management (SCIM) to automate the following P4 commands:

  • p4 group to create groups, change the users in a group, and delete groups

  • p4 user to create and delete users

You can set user passwords in your P4 client, or set user passwords in your cloud service provider. If you set user passwords in your cloud service provider, the P4 Authentication Service-based provisioning sets those same user passwords in the P4 Server. Similarly, you can find out through your cloud service provider the list of P4 users and groups.

If you use the P4 Authentication Service-based provisioning service to assign a user or a group to P4 Authentication Service (and/or P4 Authentication Service-based provisioning), you are responsible for setting the appropriate P4 protections (see p4 protect in P4 CLI Reference).

Similarly, you are responsible for making sure the groups and users in your P4 Server and cloud service provider remain synchronized.

The cloud service provider might be able to do a sync and discover any groups or users created directly in P4, but the P4 Server cannot query the cloud service provider.

How to reactivative a user

If you make a user inactive, that user is logged out and that user's password loses validity.

Suppose you want to restore that user as an active user:

  • If the user authenticates with SSO, enable the user within the cloud service provider, such as Azure AD

  • If that user has a P4 Server password:

    • reset the password in the cloud service provider's provisioning feature

    • If the cloud service provider is not managing user passwords, reset the password with the P4 Server p4 passwd command

Multiple P4 Servers

If you want to allow one P4 Authentication Service instance to connect to multiple P4 Servers, configure the provisioning setting for each server. This example shows two servers, one in the United States (p4port = "ssl:chicago:1666") and one in Japan (p4port = "ssl:tokyo:1666").

[provisioning]
[[provisioning.providers]]
bearer_token_file = "feline-token.txt"
domain = "feline"

[[provisioning.providers]]
bearer_token_file = "canine-token.txt"
domain = "canine"

[[provisioning.servers]]
p4port = "ssl:chicago:1666"
p4user = "super"
p4passwd = "2E7092CC2CA6BCAC74EB364BF4C4AD99"
domains = [ "feline", "canine" ]
leader = [ "canine" ]

[[provisioning.servers]]
p4port = "ssl:tokyo:1666"
p4user = "super"
p4passwd = "C8478F3F32B62A84731ADDB5A2443E68"
domains = [ "canine" ]

where:

  • Each Cloud service provider is defined in its own provider section.

  • Incoming requests are assigned to a domain based on the bearer token that is used by the client.

  • Each P4 Server instance is defined in its own [[provisioning.servers]] section, and each server can belong to one or more domains.

The configuration example above uses the TOML file format.

Constraints:

  • Each provider must have its own bearer_token_file

  • If multiple servers are assigned to a particular domain, exactly one of them must have that domain listed in their leader list. In this example, the server associated with Chicago is the leader.

  • Each domain name must be unique. The name can contain letters and numerals. Except for underscores, no special characters or blank spaces are allowed in domain names.