Legacy MyProxy Authentication
The legacy MyProxy authentication method exchanges end-user credentials for special, time-limited credentials that Globus uses to perform transfer-related activities on the user’s behalf.
Please try to use anything else
Legacy MyProxy authentication is only suitable when you are unable to use CILogon or MyProxy OAuth. Please try to at least use MyProxy OAuth.
Moderate Risk? Use CILogon
If you have Moderate Risk data, then two-step is required. That means you must use the CILogon authentication method (it is the only one which supports two-step at this time).
Here is how legacy MyProxy authentication works:
The end user chooses to use your Globus Connect Server endpoint.
Globus asks the end user for their username and password.
Globus establishes a secure connection with the MyProxy service running on your endpoint, and sends you the username and password provided.
MyProxy validates the credentials. If valid, a short-lived client certificate & private key are generated, and sent back to Globus.
Legacy MyProxy is the least-preferred authentication method because, for it to work, the user must give Globus their local username and password.
When Globus communicates with your endpoint, it uses the client cert issued by MyProxy, which contains the end user’s local username. That is how your endpoint knows who is using Globus.
To use legacy MyProxy authentication, you will be making additions to the
globus-connect-server.conf file that you first filled in during initial
Perform initial configuration first
If you have not already completed the initial configuration, do that first, and then come back here.
Here is the content which needs to be added to the
Each of the sections will now be discussed in detail. If you do not need this explanation, you can skip ahead.
Security section is very simple:
[Security] FetchCredentialFromRelay = True IdentityMethod = MyProxy
globus-connect-server-setup to configure MyProxy. The
explanation for FetchCredentialFromRelay is a little more complicated.
TLS is used to secure the communications between Globus and your endpoint.
With TLS, the server side must have a private key and certificate (if you run a
web site, you are probably aware of this already). Since Globus is initiating
connections to your endpoint, your endpoint needs a private key and
certificate. The FetchCredentialsFromRelay setting tells
globus-connect-server-setup to fetch a key and certificate from Globus, which
will be used for all future connections from Globus.
MyProxy section is also simple, with two options that can be changed
(although that is not normally required):
[MyProxy] Server = %(HOSTNAME)s ;;ServerBehindNAT = True
Server and ServerBehindNAT influence how
configures your endpoint.
Normally, your system’s hostname should match what is in Public DNS. But, in
some cases (such as when you are behind a NAT), that is not the case. When
your hostname does not match what is in Public DNS, you need to set Server to
your name in public DNS, and set ServerBehindNAT to
True. That will force
globus-connect-server-setup to configure MyProxy with the settings you
globus-connect-server.conf has been completed, it is now time to run
You should now run the
globus-connect-server-setup command. When you run
this command, you will be asked for your Globus ID’s password. Once that is
provided, setup will commence.
'sslv3 alert handshake failure' is OK
If you are running globus-connect-server-setup on a system running Python 3.1 or older, you may get the message 'sslv3 alert handshake failure'. This may be safely ignored. It is happening because your older Python is missing support for TLS SNI, which is required by downloads.globus.org (the Globus package repository). This issue has been reported to Globus.
Repeatedly prompted for ID and password?
If you are being repeatedly prompted for your Globus ID and password, that normally means that one of the two are incorrect. Remember, when prompted for your Globus ID, only enter the part before the at-sign.
Here is an example of the output from a successful run of
Password: Configured MyProxy server on sci-nfs-1.stanford.edu:7512 CA DN: /O=Globus Connect Server/CN=sci-nfs-1.stanford.edu Configured GridFTP server to run on sci-nfs-1.stanford.edu Server DN: /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=3af50398-3961-11e8-b98d-0ac6873fc732 Using Authentication Method MyProxy Configured Endpoint quake-sci-nfs-1
globus-connect-server-setup is performing these steps:
Checking for newer versions of Globus Connect Server.
globus-gridftp-serverservices, and performing basic configuration for both services.
Creating a local certificate authority, which MyProxy will use to issue client certs.
Requesting a server certificate and private key from Globus, which MyProxy and GridFTP will use when accepting connections from Globus.
If configuration was successful, the “Configured endpoint” message will be printed. At this point, services have been started and are ready for use!
Write down your Server DN
The Server DN is needed later in the configuration process, so make a note of it, until configuration is complete.
Now that Globus Connect Server (or, more specifically, MyProxy and GridFTP) is (are) up and running, you should finish configuration.