000033343 - Example of using curl commands to pass Web Services commands to RSA Via Lifecycle and Governance

Document created by RSA Customer Support Employee on Jun 17, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000033343
Applies ToRSA Product Set: RSA Via Lifecycle & Governance, Identity Management and Governance
RSA Version/Condition: 7.0, 6.9.1
 
IssueThis article will give an overview of using the Linux curl command to interact with our Web Services interface.
ResolutionBy default Web Services is not enabled within RSA Via Lifecycle and Governance.
To enable Web Services:
  1. Login to the RSA Via Lifecycle and Governance Administrative interface (e. g., https://servername.domain.com)
  2. Under the Admin menu select Web Services.
User-added image

  1. On the Web Services page click Edit and change the Web Services Interface from off to On.
  2. By default the server only allows connections from itself (i. e., 127.0.0.1).  You can either add additional hosts or clear the loopback IP address to allow any host while you are testing.
  3. Click OK when done.
User-added image

 
  1. Now that Web Services is enabled here is a sample of logging in, obtaining an authentication token, and providing that token to execute an authenticated command.
    1. First open an SSH session to the RSA Via Lifecycle and Governance server and authenticate as a user with the command below (note that the command should be entered on one line):

curl -k -H "Content-Type: application/xml" -X POST -d '<username>AveksaAdmin</username><password>Aveksa123</password>' 
"https://127.0.0.1:8443/aveksa/command.submit?cmd=loginUser"


  • Here is a breakdown of the above command:
curl is the Linux command
-k / --insecure , This option tells the curl command to not validate the certificate chain presented.  
If you wanted you could export our self signed certificate or your replacement certificate hierarchy as individual PEM files in a folder and leverage curl's --capath option to enable certificate validation.
-H , This option defines the header that is being passed to Web Services.  In the above example we are identifying our traffic to Web Services as being of type application/xml.
-X , This option defines what request command we are passing. (GET/POST/PUT/DELETE).
-d , This option is the data that we are sending.
<username> </username> In between these tags is the User that is authenticating.
<password> </password> In between these tags is the password that is associated with the user.  Note that both username and password tags are case sensitive.

  • Here is a detailed breakdown of the URL appended to the command:

https or http can be used.  If using http your server must be configured to allow non-secure connections.
127.0.0.1 - This is the server to which the connection is made.
:8443 - This is the default port used for the JBoss/Wildfly application servers.  This port should be the same port that your Administrative Web Interface is using.
/aveksa/command.submit?cmd= - This is the prefix for all commands that will be passed, this is the target that parses the commands.
loginUser - This is the actual Web Services call/command that is being performed.

  1. Note that on the Admin/Web Services page in the Administrative Web Interface you can hit the down arrow next to each command for a description and arguments that are required.
  2. Now running the command with the output looks like (again, all on one line):

#curl -k -H "Content-Type: application/xml" -X POST -d '<username>AveksaAdmin</username><password>Aveksa123</password>' 
"https://127.0.0.1:8443/aveksa/command.submit?cmd=loginUser"

token=ws3137f59972b7c7967f:-12d86acf:154bb48bc96:-7fd40.19157109468220368


  1. The token value returned above is then used to run an authenticated command getSecuritySettings:

#curl -k -H "Content-Type: application/xml" -X POST "https://127.0.0.1:8443/aveksa/command.submit?
cmd=getSecuritySettings&token=ws3137f59972b7c7967f:-12d86acf:154bb48bc96:-7fd40.19157109468220368"
allow-username-save=false
token-lifespan-timeout=120
token-inactivity-timeout=10


  1. The -d data option is omitted as username and password are not required because we are now leveraging the token that was returned.  We can continue to use the token until it expires.  We can also use a keepAlive Web Services call to reset the inactivity timeout if needed.
  2. The loginUser was replaced with getSecuritySettings.  An & is added after the command and the full token=value is appended to the URL with a closing quote at the end.
  3. The result of the above query returns our user defined security settings for Web Services.  Whether we allow saving the username, the token lifespan/absolute timeout, and the token idle/inactivity timeout.
  4. Here is an additional example of a command that is documented within Web Services:
#curl -k -H "Content-Type: application/xml" -X POST "https://127.0.0.1:8443/aveksa/command.submit?
cmd=findUsers&returnColumns=id,user_id&&token=ws3137f59972b7c7967f:-12d86acf:154bb48bc96:-7fd40.19157109468220368"

id=0
user_id=AveksaAdmin

 
NotesFrom the curl man page:

curl is a tool to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command is designed to work without user interaction.


curl offers a busload of useful tricks like proxy support, user authentication, FTP upload, HTTP post, SSL connections, cookies, file transfer resume, Metalink, and more. 

Attachments

    Outcomes