How to setup the connection in Octopus to login a SaaS application?

Advice
1

Hi,

We are recently trying to automated our deployment via Octopus. The product we trying to connect is a SaaS application, which contains two interface, one is Dev interface - this can create the build package. the other one is the deployment and data interface - this can install the packages and do the configuration changes.

My thoughts are

1: Ask Octopus to talk to the Dev interface and start the build, send the package to Octopus folder.
2: Ask Octopus to talk to the deployment interface and install the package and check the configuration as desired.

I am stuck looking for some information if Octopus can login a SaaS interface with username and password.

Please advice.

Thank you,
Rachel

3

Hi @rachel.dong

Thanks for getting in touch with Octopus and the question!

I’m interested in understanding your two ideas some more. In both situations, it sounds like the 2 interfaces of the SaaS application are capable of handling both builds and deployments. How does Octopus fit into this model for you? Are you intending it to be a scheduling orchestrator only?

A typical CI/CD pipeline would involve something outside of Octopus (a CI server) building your code and generating a package, and then this would push the packages to Octopus and it would then deploy your package.

In short, the answer is, it depends. Octopus at its heart is a script runner, which executes deployment steps and runbook runs on behalf of either a user or an automated trigger (scheduled or otherwise).

Octopus is capable of executing web requests and therefore could authenticate (or login) to a SaaS application. However, it was never intended to simulate a user logging in and performing actions that a user would do.

Therefore if the SaaS application in question had an HTTP API where you could perform the same functions a user would perform, then it’s possible.

Without knowing what the SaaS application is, unfortunately, I can’t give a more specific answer.

Best regards,
Mark

4

Thank you Mark, for your quick response.

The product we are using is called Avoka, it is a SaaS product but it also provide with REST API calls to allow us to do the script from.

So when I meant Dev interface, it is actually meaning the Developing interface as the target, which is the Maetro product (Journey Maestro).

And the deployment interface it is the journey manager
product that are the target where we do the deploy (Journey Manager)

We had in the past did some automation work through node and selenium with calling their REST API. All calls to the REST API use the basic authentication header.

Do you have some code snippet or some examples for me to look into how the login works with octopus?

Thank you,
Rachel

5

Hi @rachel.dong

Thank you for the additional information.

I’ve not used the Avoka product, and we don’t have native integration with it, so my answers will be limited to high-level concepts.

I did a quick scan across the Journey Maestro link you provided and couldn’t see examples of using a REST call, although was lots of mention of the Journey SDK, which itself may include further details on making the calls.

In terms of making an HTTP request to a REST endpoint to login, assuming the endpoint can return JSON data, the following example could be used within a PowerShell script step in Octopus to make a request using Basic Authentication:

# Step 1. Create a username:password pair
$credPair = "$($username):$($password)"

# Step 2. Encode the pair to Base64 string
$encodedCredentials = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($credPair))

# Step 3. Form the header and add the Authorization attribute to it
$headers = @{ Authorization = "Basic $encodedCredentials" }

# Step 4. Make the request
$response = Invoke-RestMethod -Uri "https://the-uri-to-avoka" -Headers $header -Method Get

You would need to replace $username and $password with relevant details. I would recommend considering the use of a sensitive variable for the password value.

I hope that helps!

1 Like
6

Hi Mark,

Thank you for your last reply.

REST Groovy Service Invoke v2 · Transact Services Guide (TSG) Looking at this document, for example, I can use this API call to get the list of the groovy service list. And in the Postman, we use the username + password in the header, i think it’s sort like how the base64 one works.

The question though we have, is how we set up the deployment process, how do we connect with the end point URL?

We dont have a AWS account where we can connect as the Deployment Target, and I am confused how should the Powershell script run against to.

I tried to add a step with above script you provided and it is also complaining about no target added.

Let me know if it makes senses.
Rachel

7

Hi @rachel.dong

Thanks for your reply.

You are correct the Username + Password in Postman will likely be Base64 encoded, it may well do that part for you, but here when you are scripting yourself, you need to do it manually.

The answer to the Execution Location will depend on where the Groovy service REST API is hosted. If it’s as you mentioned at the start, and a SaaS product that is available in the cloud, and over the public internet, you can run the script on any deployment target or worker you like so long as the server where the script runs can connect to the API in question (including opening any firewall rules).

Let’s assume that the REST API can be connected to over the internet:

In your deployment process, you would add a PowerShell script step.
In the Execution Location, if you have no workers configured in your Octopus instance, you’d see something like this:

image
image1431×753 63.8 KB

This allows you to run the script on the Octopus Server itself.

If you have a worker configured, choose the worker pool to run the script on:

image
image1449×789 66.8 KB

As I shared before, run the script, substituting the username, password, and the URL to the REST API:

image
image1268×606 77.3 KB

I’ve copied the script contents here, and taken the example Groovy REST API URL, you should replace that value with wherever the REST API you want to connect to is hosted:

# Step 1. Create a username:password pair
$credPair = "$($username):$($password)"

# Step 2. Encode the pair to Base64 string
$encodedCredentials = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($credPair))

# Step 3. Form the header and add the Authorization attribute to it
$headers = @{ Authorization = "Basic $encodedCredentials" }

# Step 4. Make the request
$response = Invoke-RestMethod -Uri "https://transact.maguire.com/manager/secure/rest/groovy-service-invoke/v2/" -Headers $header -Method Get

From there, the $response variable would contain details of the services. You are able to use that data however you wish.

I hope that helps.

Best regards,

1 Like
8

Hi @mark.harrison Thank you for your help! we have worker configured and now i am able to get response to the public REST API call.

9

Hi @rachel.dong

You’re very welcome.

I’m glad you were able to get the response from the REST API call :slight_smile:

Happy deployments!