Question

Does LF Workflow HTTP Web Request not support this authenticaiton method?

Workflow

Updated July 15, 2021

asked on July 7, 2021

This Bamboo HR REST API is well documented but uses a strange way of authenticating, instead of creating a header or putting the key in as a variable, the key is in the URL separated by an @ symbol. It does work using Chrome as a test.

However when trying to use the HTTP Web Request object I get an error in all tests. The error details are "The underlying connection was closed: An unexpected error occurred on send. Request failed with status code 500: SendFailure"

https://{apikey}:x@api.bamboohr.com

0 0

Answer

SELECTED ANSWER

replied on July 7, 2021 • Show version history

I wonder if this might be a TLS version issue where the BambooHR API endpoint only accepts TLS 1.2+ and Workflow isn't configured to be able to use TLS 1.2, so Client and Server and unable to find and agree on a mutually supported protocol version in the TLS handshake.

You should be able to see that in the details of the TLS handshake in the Wireshark trace. Upgrade Workflow to 10.4.3 or 11 and apply the usual reg keys.

1 0

Replies

replied on July 7, 2021

I believe the "username:password@hostname" syntax is just convenience for using HTTP basic authentication. I don't think the syntax is really supported outside of browsers, which is why it doesn't work in Workflow.

2 0

View 9 previous replies

replied on July 7, 2021 • Show version history

I think Brian is correct. From what I understand that syntax is just something you can do in a browser for Basic Authentication.

So setting it to Basic Authentication and putting the credentials there should work.

0 0

replied on July 7, 2021 • Show version history

I had tried this already because they did say they support basic authentication. I just tried again. The way W3 schools says to use Basic Auth in the headers is to use the Authorization header and just type the word Basic out manually followed by a space character and then your credentials separated by a colon.

I get the same exact send error though, I cleaned up the credentials and @ stuff from the domain and made sure everything was configured correctly.

Here is their statement:

At the HTTP level, the API key is sent over HTTP Basic Authentication. Use the secret key as the username and any random string for the password.

0 0

replied on July 7, 2021 • Show version history

You received the same error when you input the credentials rather than manually adding the authorization headers?

I have several Web Services we utilize in Workflow that require Basic Authentication and I've always just put the credentials in the "Use the following credentials" space within the web service configuration.

Based on the BambooHR API documentation, it looks like you can put any string for the password as long as you use the correct API key as the username.

Basically, just try taking the "{API Key}:x@" portion out of the Web Service URL, then put the API key into the username field and any string into the password field.

0 0

replied on July 7, 2021 • Show version history

Just tried this without any luck, same exact send error. What I find odd is that I am not getting a username or password incorrect error. It is almost just as if the remote server which hosts their API does not like something about the request send using the HTTP Web Request activity.

Look how it just sends a combined RST and ACK of it's own RST all at once. It is basically just slamming the door before we even get started communicating.

See how much different a web browser call is. A RST should not be sent from the server until I say goodbye or they don't trust me

0 0

SELECTED ANSWER

replied on July 7, 2021 • Show version history

You should be able to see that in the details of the TLS handshake in the Wireshark trace. Upgrade Workflow to 10.4.3 or 11 and apply the usual reg keys.

1 0

replied on July 7, 2021

I have run into this kind of stuff before, where it is not very well documented.

It doesn't mention this in the error message. Where in wireshark can I check for this?

I just reviewed the documentation from Bamboo HR to ensure it doesn't say any special TLS is required.

0 0

replied on July 7, 2021

This post provides a pretty thorough walkthrough of the relevant bits:

https://www.catchpoint.com/blog/wireshark-tls-handshake

You're looking for the "Version" field in the Client Hello:
"Version: The TLS protocol version number that the client wants to use for communication with the server. This is the highest version supported by the client."

If Workflow is configured to use TLS 1.2, you should see a value of "TLS 1.2 (0x0303)". If it says TLS 1.0 or TLS 1.1, that may be the issue. You can verify this by looking at the subsequent Server Hello message's Version field:
"Server Version: The highest TLS protocol version supported by the server which is also supported by the client."

If Client and Server don't have a mutually supported TLS protocol version to agree on, the handshake fails. It's also possible for Client and Server to agree on a protocol version but not a cipher suite (like "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"), which causes a similar handshake failure.

I used Qualys' public SSL Lab's tool to scan at least one of the api.bamboohr.com endpoint IPs and it seems to still support TLS 1.1, so the version may not be the problem. Looking into the details of those calls in Wireshark might provide other useful insights either way though.

To point out a general trend though:

The major browsers have at this point officially depreciated TLS 1.0 and 1.1 after a few years advanced notice.
Microsoft has/is disabling TLS 1.0 and 1.1 for Microsoft 365 services.
Laserfiche Cloud ended support for TLS 1.0 and 1.1 as of January 1, 2021.
Salesforce disabled TLS 1.1 in 2019.

Many organizations have been working to disable TLS 1.0 and 1.1 on their systems for a while now to stay compliant with cybersecurity and regulatory standards (e.g., TLS 1.0 is now an auto-fail for PCI compliance; NIST SP 800-52 Rev.2 requires TLS 1.2 or higher for all govt orgs) and most probably didn't make announcements about it. Over the next year or two, it's an increasingly safe assumption that anything lower than TLS 1.2 will be disabled.

1 0

replied on July 8, 2021

My Wireshark says TLSv1. Does that mean TLS version 1.0?

I upgraded to Workflow 10.4.2.246 which is the version that comes with the latest release of the 10.4.3 package from last summer.

It does not provide any options to choose which TLS I would like to use though and still says TLSv1 in Wireshark.

Thanks for all your help on this! I really hope some security requirement isn't the reason for so much pushback on this test, I feel like their documentation is really good and I had their API working within minutes. Seems like it takes many hours to get it working in Workflow.

0 0

replied on July 8, 2021

That's what Sam is saying. Workflow will use TLS 1.0 by default in 10.4.2 or lower because that is what .Net defaults to. The registry keys in this KB article are required to direct .Net 4.5 or lower to use the latest version available in the OS.

Choosing the TLS version in the application is not a recommended setup across the industry because it results in insecure configurations in the long term as older cyphers and protocols are obsoleted.

The 10.4 package is updated monthly as described in this KB article to include patches and newer versions. As of November, it contains Workflow 10.4.3.

1 0

replied on July 8, 2021

I can only find an August 2020 package of 10.4.3 BUT I re-downloaded and it did work to upgrade my workflow to 10.4.3. However my Win 10 laptop does not have the Key specified in the instructions for TLS. Do I create Keys that do not exist or do I need to do this on the productions server?

0 0

replied on July 8, 2021 • Show version history

You don't need to set the SCHANNEL Protocol keys on Windows 10 or Windows Server 2012 R2+, as those have TLS 1.2 enabled in SCHANNEL by default.

You do need to set the .NetFramework and WinHttp ones on the server running Workflow. The following PowerShell sets those keys:

# Enable TLS 1.2 for .NET Framework 4.5+ x64/x86
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -value '1' -Type 'DWord' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type 'DWord' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type 'DWord' -Force | Out-Null


# Enable TLS 1.2 for WinHttp x64/x86
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp' -Name 'DefaultSecureProtocols' -Value '2048' -Type 'DWord' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp' -Name 'DefaultSecureProtocols' -Value '2048' -Type 'DWord' -Force | Out-Null
New-Item 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp' -Name 'DefaultSecureProtocols' -Value '2048' -Type 'DWord' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp' -Name 'DefaultSecureProtocols' -Value '2048' -Type 'DWord' -Force | Out-Null

2 0

replied on July 9, 2021

This powershell code worked immediately! Thank you!

Thanks to everyone for contributing to this. I would have never figured this out as there is no mention of it in their documentation. Talk about security through obscurity.

1 0

replied on July 7, 2021 • Show version history

Perhaps try URL encoding the @ symbol as "%40". You might also need to URL encode the second ":".

https://stackoverflow.com/questions/19509028/can-i-use-an-at-symbol-inside-urls/19737890

People seem to indicate that modern browsers like Chrome automatically do the URL encoding for you. I suspect Workflow does not and requires that you provide a pre-encoded URI.

0 0

replied on July 7, 2021

Googled to ensure the : is an accepted character. It is when using it like this.

Swapped out @ for %40 and get "Invalid port specified"

0 0

replied on July 8, 2021 • Show version history

From the documentation, it says that it accepts HTTP Basic Authentication. To use HTTP Basic Authentication in the header, the documentation says to use the API Key as the username and any random string as the password with a Colon (:) separating the two. What it does not say, but links to a Wiki page about Basic Access Authentication, is that the data after the word Basic needs to a Base64 string.

So the first thing you want to do is add a Script Activity to encode the username:password into a base64 token

            Dim sKey As String = "{API Key}"
            dim sSecret As String = "Secret"
            Dim ba() As Byte = System.Text.Encoding.UTF8.GetBytes(sKey & ":" & sSecret)
            settokenvalue("Base64Auth", Convert.ToBase64String(ba))

Then in your Web Request Activity, click the "gear" icon to get the advanced properties.

In the Request Headers, add Authorization in the first column and in the second column add "Basic %(Base64Auth)"

2 0

replied on July 15, 2021 • Show version history

I have a question regarding another API that is requesting TLS1.2

This customer is developing their workflows from a remote workstation running workflow designer locally. If I enable TLS1.2 using this method, does that force their designer on their workstation (when using the test options) to use TLS1.2 or do they need to tell their workstation to use TLS1.2 as well?

This is why, since the industry is choosing to be picky about specific versions used, it would be nice to have a checkbox in the interface. What version of TLS do you want to use for your connection?

0 0

replied on July 15, 2021

Hey Chad,

Enabling TLS 1.2 for .NET and WinHttp on the remote workstation with Workflow Designer using those PowerShell commands will make it use TLS 1.2 with that API since it will be the highest mutually supposed TLS version. Of course make sure it's enabled on the actual Workflow server as well.

In Transport Layer Security (TLS) best practices with the .NET Framework Microsoft specifically says:

To ensure .NET Framework applications remain secure, the TLS version should not be hardcoded. .NET Framework applications should use the TLS version the operating system (OS) supports.

Laserfiche 11 apps follow that guidance by default now by merit of using .NET 4.7.1 or higher.

0 0

replied on July 15, 2021

Ok great! Sounds like I will go with version 11 for this install which will keep us out of the registry modifications.

0 0

replied on July 15, 2021

If their Designer is 10.4, you'll also need to do the registry configuration on the workstation since testing calls to the 3rd party API will be from the workstation. If it's 11, it will use the machine's default TLS settings (which should be TLS 1.2 for any reasonably patched Windows 7 and higher OS).

0 0

replied on July 15, 2021

Oh so version 11 references the Microsoft Framework's default?

Which just keeps itself up to date as new versions come out?

This means if I install version 11 on the server as well, then there is no more registry modifications required?

0 0

replied on July 15, 2021

Yep!

0 0

replied on July 15, 2021

They all reference the .Net framework default. But the default was TLS 1.0 in .Net 4.5 (used by Workflow 10.x and lower) and it is OS default in .Net 4.8 (which is used by Workflow 11). The OS defaults to TLS 1.2 these days (by default in Windows 8.1 and 10 and after applying patches in Windows 7 - this patch was pushed out through Windows updates more than a year ago)

0 0

You are not allowed to follow up in this post.

Question

Question

Does LF Workflow HTTP Web Request not support this authenticaiton method?

Answer

Replies

Sign in to reply to this post.