Escolar Documentos
Profissional Documentos
Cultura Documentos
1.0 Overview:
Workday Web Services requires authentication in order to make a webservice call using the SOAP API.
Although it is common to use username/password authentication, Workday allows for the use of X509
authentication as an alternative. At a high level, X509 authentication requires the following:
The steps noted above will be outlined in detail throughout this document.
In a production environment, the certificate used to establish communication between the webservice
client and Workday should be signed by a CA, which is considered a trusted authority. This certificate is
composed of a private/public keypair, where only the public key is saved in Workday, while the private
key is used to create the signature on the webservice call. For testing purposes, a self-signed certificate
can be created. The following steps outline how this can be done for a Java webservice client, and
different steps may be used for webservice clients written in different languages.
A utility called keytool is included with the standard Java JDK, and allows for the creation of a
self-signed certificate. In addition, this tool allows for the import of a certificate into an object
called a keystore, which a Java client can then use to make webservice calls. The following
command will create a private/public keypair and then store the resulting certificate containing
the keypair in a keystore(Note that before running this command, it should be verified that the
path to %JAVA_HOME%\bin is included in the %PATH% variable, as this is the directory that
contains the keytool utility):
Alias – This is a “name” for the keypair which is being constructed. Because a keystore
can hold multiple keypairs, it is necessary to give this new keypair an alias, or a name. In
the case of the above command, the alias MySOAPTest has been specified. When a key
is looked up from within the keystore, this alias will be needed.
keyalg – This specifies the algorithm used to create the key. In this case it uses the RSA
algorithm.
Keystore – This is the name of the keystore file which the key will be added to. If this
keystore does not exist, it will be created. In this case, no directory path is specified, so
the keystore is being created in the current directory.
When the above command is executed, it will ask several questions pertaining to the creation of
the certificate. These would be the types of questions which would be asked if a valid certificate
was being obtained from a CA. In this case, however, keytool is acting as the CA and signing the
certificate. In addition, you will be asked for a password for the keystore. Be sure to remember
whatever password is chosen.
After the command completes, the contents of the keystore can be verified using the following
command:
After the keypair has been created, the public key must be extracted from the keypair, since this
is what will be stored in Workday. The public key can be extracted using the following
command:
This will create the MySOAPCert.cer file, which will contain the certificate contents as follows:
The contents of this file will be stored in Workday as the public key.
In Workday, search for the Create x509 Public Key task, as shown below:
You will be prompted to enter the information shown below. In the Certificate field,
copy and paste the public key from the .cer file which was created.:
Search for the integration system user which will be used to make the SOAP
request(Note: Permissions must be configured for this user for the necessary web
services, which is outside the scope of this document).
Select the Enable X509 Token Authentication, and choose the public key which was
created in the previous step:
The following example shows a webservice client which has been written in Java. This client
does not use the WSDL to construct the SOAP message. Instead, it will read the message from
an XML file, append the necessary signature, and send the full request to the tenant:
The following is a sample XML file containing the SOAP request. Notice that the
integration system user INT999@bah2 was specified, and this would need to be
modified according to the integration system user which you have configured:
The complete XML file is embedded here:
samplewithoutnonce.
xml
The following Java code uses the Java XML digital signature API to create the signature, append
it to the XML, and send the SOAP request:
The above Java code will also write the resulting SOAP call, including the signature to the file
signature2.xml, which is as follows:
Notice how the signature as well as the certificate have been added to the SOAP call, as these are
needed for the X509 authentication. Workday will then decrypt the signature using the public key which
was previously imported.
signature2.xml