Rubrik API Logins through vRealize Orchestrator

Part three of this series focuses on how Nick Colyer and I built the authentication piece of the plugin so that we could then pass commands to the Rubrik appliance. An API requires a login just like any other portal would. Since this is a a REST API, we actually need to do a “POST” on the login resource to get ourselves an authentication token.

Download the Plugin from Github

NOTE: The first version of this code has been refactored and migrated to Github in Rubrik’s Repository since the time of this initial writing

To begin, lets look at the whole workflow.

INPUTS: Username of type String, Password of type SecureString

OUTPUTS: Token of type String

We’ll be performing the following operations:

• Format Login Request – Here we want to get our username and password formatted correctly to pass to the REST host.
• Retrieve Rubrik Token – This is where we pass our login information over to the REST host with a POST on the /login resource
• Output Token – We pass the token to this element and log it.
• base64Encode – convert the token into base64
• Log Base64Token – Log the base64 Token

The first element in the workflow attempts to format our username and password so that it can be passed in a REST call. We see from the visual binding that we have inputs of Username and Password and an output of “postText” which will be the string we pass to our POST rest call.

The scripting tab is where we’ll do the the hard work of formatting the request. The string should look something like {“userId”:”username”,”password”,”password”} when we’re done (assuming we have a userId of username and a password of password). When we’ve got our string formatted, we log it so that we can be sure it’s being created correctly.

Note: If you’re wondering why the string has extra “” in it, that is because the code vRO uses is javascript and in javascript the “” is an escape character. Meaning I can add quotes without javascript thinking it is anything other than a text character.

The next step is to call a workflow that will do our REST call to Rubrik. We pass the postText parameter to the new workflow. Inside this workflow we have a scriptable task to make our REST call and we pass it the postText variable which has been named “content” in the new workflow. The scriptable task also needs to know the REST operation we are going to perform this item has been statically assigned as an attribute. We know any time that this is run, we are asking for a POST on the https://Rubrik.local/login resource.

Now we move on to the scripting tab. This is where the magic happens. We need to modify the section under the “//set the request content type” section. We added a line to set the contentType = “application/json” and then we log the URL so that we know that its correct. The next piece that needed to be added was the “request.setHeader line” where we tell it to Accept the application/json format. The rest of the code will execute the REST Call.

Notice the “content” variable is part of the request. This is where we pass the username and password to the Rubrik array.

From here, we’ve executed a POST to the appliance and have gotten a token (or cookie if you prefer that term) from the appliance. We pass this token to our next element where we log and format it. You can see from the visual binding tab that we take the output token from the previous element and will output a RubrikToken.

The scripting tab shows how we parsed out the token information. The first thing we did was create a new variable and parse the content since it was in a JSON format. Once we have that information we append a “:” to the end of it because the base64 version of the token requires a username:password format. Password in this case is an empty set so we only add a colon to the end of the string. We take this content and output it as our RubrikToken attribute.

The next piece, Nick and I take no credit for. This is some code we got directly from Crypto-JS project. This piece of code converts our Rubrik Token into a Base64 token that can be passed for authentication purposes. See the below disclaimer for more information. A BIG thanks to these guys for writing this nugget of goodness.

(c) 2009-2013 by Jeff Mott. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation or other materials provided with the distribution.
• Neither the name CryptoJS nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS,” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The last step we do is to log the base64 Token before then adding it to a workflow output. This is done so that the entire workflow requires a username and password, and outputs just the base64Token so that we can use it over and over.

If you’re worried that this is too complicated to deal with, don’t worry. The plugin we created is neatly packaged into a single action so that all the pieces you saw above look like a single element requiring a username and a password and they output a base64Token. If you want more information about how to use this action from the plugin, head on over to SystemsGame.com for the details.

Below is an example of the logs generated when running the workflow. This should help to understand the process a little better.

Summary

You’ve made it this far, we now have a token that we can use for authentication purposes. Check out the next post in the series to see how we can actually use this code to do something useful with the Rubrik Hybrid Cloud Appliance.