Contents
Problem Statement:
Solution:  P4Auth
Advantage of Perforce centralized authorization server
Overview of P4Auth
How to Implement?
Verification: centralized authorization server
Configure outer server to listen central authorization server
Commands to the central server
Limitations and notes
FAQ
Reference:

Problem Statement:

Prepare a report on Perforce Servers Automation which consists of following requirement.
We need to develop a centralized web based tool which will control and manage all the perforce Servers instance and Minimize the time spending on admin work related to following…
1. User Creation /Deletion
2. Group Creation / Deletion
3.  Assigning Depot Access to group such as modifying protect table

Solution:  P4Auth

The feature (centralised server) you are looking for has been available Undocumented for several years. However since the 2010.2 release, it is now fully supported and documented.
In multiple perforce Server scenario, we can configure them to retrieve protections and licensing data from a centralized authorization server.

Advantage of Perforce centralized authorization server

• By using a centralized server, we are freed from the necessity of ensuring that all your servers contain the same users and protections entries.

• If a user does not exist on the central authorization server, that user does not appear to exist on the outer server.

• If a user exists on both the central authorization server and the outer server, the most permissive protections of the two lines of the protections table are assigned to the user.

• We can use any existing Perforce Server in your organization as your central authorization server.

• The license file for the central authorization server must be valid, as it governs the number of licensed users that are permitted to exist on outer servers.

Overview of P4Auth

• Allow multiple edge servers to authenticate off a central server.
• Introduced in 2002.2. However since the 2010.2 release, it is now fully supported and documented.
• Undocumented and officially unsupported till 2010.1
• See 'p4 help undoc' for documentation.
• Shares protections, groups, users, and passwords with the central server.
• Servers need constant access to the central server. If the network connection is down no commands can be authenticated.

How to Implement?

To configure a Perforce Server to use a central authorization server, set P4AUTH before starting the server, or specify it on the command line when you start the server. Setting P4AUTH by means of a p4 configure set P4AUTH=server:port command takes effect immediately.

• Pass -a to p4d at startup point to the central server or set P4AUTH=<ip:port> and restart the server.
• Protections table entries that use IPs need to be Prefixed with proxy- for clients connecting through edge servers.
• The user 'remote' account needs to be configured on the central auth servers.

Verification: centralized authorization server

If your server is making use of a centralized authorization server, the following line will appear in the output of p4 info:

Authorization Server: host:port

Where host:port refer to the host and port number of the central authorization server.

Configure outer server to listen central authorization server

In the following example, an outer server (named server2) is configured to use a central authorization server (named central). The outer server listens for user requests on port 1999 and relies on the central server's data for user, group, protection, review, and licensing information. It also joins the protection table from the server at central:1666 to its own protections table.

For example:
p4d -In server2 -a central:1666 -p 1999

Commands to the central server

Central authorization server, outer servers forward the following commands to the central server for processing:

Limitations and notes

• All servers that use P4AUTH must have the same unicode setting as the central authorization server.
• Setting P4AUTH by means of a p4 configure set P4AUTH=server:port command takes effect immediately. You do not have to stop and restart the outer server.
• To ensure that p4 review and p4 reviews work correctly, you must enable remote depot access for the service user (or, if no service user is specified, for a user named remote) on the central server.
• To ensure that the central server correctly distinguishes forwarded commands from commands issued by trusted, directly-connected clients, you must define any IP-based protection entries by prepending the string "proxy-" to the IP address.
• Protections for non-forwarded commands are enforced by the outer server and use the plain client IP address, even if the protections are derived from lines in the central server's protections table

FAQ

When we create Centralized Authorization server, how does it impact on performance, considering perforce servers are located in multi-site location such as India-USA-Canada-Australia etc etc?
High latency network between the centralised server and outer servers may have Some performance impact. Perforce team have not conducted any performance Benchmark test for this. We need to look into this and find out feasible solution for this.
Many commands such as group, groups, passwd, review, reviews, user, users, protect, protects, login, logout is hitting to  central server, Does it create huge process queue in central perforce server imagining min. 500 user is using these commands in one point of time? How this will be tackled?
Perforce is able to handle a large number of requests. Therefore from a performance point of view, the bottleneck will be the centralised server hardware. As I mentioned, some customers have been using centralised servers for many years and I am not aware of anyone having significant performance problem because of this feature.
Can I imagine a web based tool which can administer 100's of perforce server instance and where employee can browse all listed depot and if they need access (read/Write/Super) on any depot/branch/codeline, they can raise a request through given interface in web tool and this request directly goes to admin(Super) of that particular Server Instance in form of an email, and he can reject/approve this access. As soon as he accept the request, new access definition should be added in perforce protection table?

This is not something you can have "out of the box" but this is certainly something that you should be able to implement using our p4php and p4perl api:

Reference:

http://www.perforce.com/perforce/r10.2/manuals/p4sag/03_superuser.html#1093172
http://www.perforce.com/perforce/r10.2/manuals/cmdref/env.P4AUTH.html

 For more info.

http://www.scmgalaxy.com/forum/perforce/