You are viewing limited content. For full access, please sign in.

Question

Question

Laserfiche ability to configure SSL in API calls

asked on July 26, 2022

We are currently trying to setup simple API calls to a system called ADP.  

We have done call before to other software and it is usually  a two step process:

1. Pass in a client ID and password to get an access token.

2. Pass in the access token and your call to get the info.

 

We are currently trying to connect to ADP.  They have these extra security items that are required.  We have had to generate certs using open SSL and send them into ADP.  Then get back a key file to put on the server - it really seems like some overkill.  We finally got the files and things generated and we are using PostMan to test.  In PostMan there is a certificate configuration:

With this part configured I have been able to do a test call to their auth url and get back a token.  However, when I try that same call in Workflow I get the following:

I don't see anywhere in workflow to configure pointing to those key files.  Anyone have an experience is doing something similar?  This is the first API we have run across that requires these keys instead of just a client id and client secret.  

0 0

Answer

SELECTED ANSWER
replied on August 24, 2022

To follow-up on @████████'s response:

Postman uses an external library called "RestSharp". Adding the RestSharp library reference to a Workflow Script activity requires resolving its several dependencies by adding those references as well. The following are instructions for the RestSharp version 108.0.1 .NET Standard 2.0 build in Workflow 11 Update 1. They should also serve as a general example for .NET Standard 2.0 library dependency resolution in Workflow Script activities. 

Whenever I reference a nuget package below, it means that you should download the package directly from nuget.org, use 7zip to extract it, and copy the .NET Standard 2.0 dll to your .\Program Files\Laserfiche\Workflow installation folder. Example of extracted nuget package path with netstandard2.0 dll (pre-copy to Program Files):

Drilling down through extracted nuget package (screenshot shows a different one):

Summary of steps:

  1. Download RestSharp from nuget
    1. RestSharp for .NETStandard 2.0 has a dependency on System.Text.Json 5.x
  2. Download System.Text.Json 5.02 from nuget
    1. The latest version of System.Text.Json is 6.x. Don’t get 6.x. RestSharp 108.0.1 (latest as of today) strictly requires 5.x and will fail if you have 6.x loaded instead.
  3. Download every .NETStandard 2.0 dependency System.Text.Json lists on nuget, except for:
    1. System.Runtime.CompilerServices.Unsafe, which doesn’t seem to be needed
    2. System.Numerics.Vectors, which seems to already exist on Windows Server 2019. If you don’t find it in the GAC, download it from nuget.
  4. In your Workflow script, add references in order:
    (If you don’t add them in this order, you might need to remove and re-add various references to resolve their own dependency warnings)
    1. netstandard version 2.0.0.0 (from GAC)
    2. System.Net.Http version 4.0.0.0 (should be in assemblies browser list already)
    3. System.Numerics.Vectors (from GAC or WF install folder)
    4. System.Buffers (from WF install folder)
    5. System.Memory (from WF install folder)
    6. System.Text.Encodings.Web (from WF install folder)
    7. System.Threading.Tasks.Extensions (from WF install folder)
    8. Microsoft.Bcl.AsyncInterfaces (from WF install folder)
    9. RestSharp (from WF install folder)
  5. Add “using RestSharp;” to the “using” statement list at the beginning of the script code. You shouldn’t need to add Using statements for any of the other references.
  6. Add this single line of code to the Execute() block of the Workflow script, which per https://restsharp.dev/v107/#restsharp-v107 is “how you can instantiate the client using the simplest possible way”:
    1. var client = new RestClient("https://api.example.com");
  7. Add this after for a simple confirmation the script doesn’t hang on the line above:
    1. MsgBox(“Success!”);
  8. Build and run the script to verify there aren’t any compile or runtime errors.
  9. Success!

 

 

1 0
replied on August 24, 2022

After we got the certs up and running, along with the calls, we used your info Sam and looks to be that we have things working.  Would be great as a feature request to pass the cert items forward using a built in activity or add a config option to the activity.  We really appreciate the ideas/help!

2 0
replied on November 15, 2022

I would like to second this request to have Workflow be able to pass these cert items instead of needing to write custom scripts.  We are seeing more and more of these API's requiring it.

1 0
replied on November 15, 2022

Native support in Workflow for OAuth and Certificate Auth with Web Service "External Objects"/activities is high on our priority list.

1 0
replied on November 16, 2022

That is great to hear.  Is there a timeframe/ETA for when it will be available?  

0 0
replied on November 16, 2022

I believe very tentatively early next year. Don't quote/hold me to that though - I haven't checked with the product team recently.

replied on November 16, 2022

Not sure - teams are currently doing end-of-year prioritization and planning so we might have a better idea on timelines in the near-ish future.

1 0
replied on January 25, 2023

Just wanted to check back to see if we had a timeframe on this?  We have a project that is needing this but we are unable to move forward until it is available.

0 0
replied on January 25, 2023 Show version history

Hi Beau, no current timeframe. However, it wouldn't be any earlier than next year, so if you have a project currently waiting on this we'd recommend proceeding with the custom scripting workaround for now.

Depending on the API you're working with, you may only need to use the custom script for the initial call to obtain an auth token, which you can then use for subsequent calls with the normal HTTP Web Request activity.

0 0
replied on January 25, 2023

Thanks for the honesty on the timeline & the suggestion.  While I look forward to this being built-in, its always fun to build something via the custom scripts.

1 0
replied on January 25, 2023

Welcome =)

I've since done more research and it appears the base .NET HttpClient library supports certificate authentication. So you don't necessarily have to go through the trouble of loading in RestSharp as described in my instructions above. A Google search for ".net dotnet HttpClient client certificate authentication" returns plenty of hits.

0 0
replied on March 3, 2023

Sam,

We have the script setup and it is returning a token.  Thanks a TON for the help with that.  Your instructions were AWESOME!  From that point forward I am hoping to use the normal "HTTP Web Request" activity and just pass the token when making the call. 

I am trying to pass the token provided out from our script via the Request Headers.

 

But in doing so, receive an error message:

 

It appears it is again asking for the cert to be passed with it.  Do you know if we are able to use the built-in "HTTP Web Request" activity after we receive that token or do all calls require the SSL cert and thus must be done via script?

1 0
replied on March 3, 2023

Thanks! It seems ADP's API is requiring the client authentication certificate to be sent with every request, so you'll have to send subsequent requests with the Script activity as well. See: Invoke-RestMethod authentication problem with ADP (required two-way TLS certificate) | Reddit

1 0
replied on March 6, 2023

That's what we are finding also, which is a bit frustrating to say the least.  Oh well, atleast we have it working & hopefully Laserfiche will update the Workflow token to pass the SSL cert with the request at some point down the road.  Thanks again for all of your amazing help!

1 0

Replies

replied on July 26, 2022

I believe the built-in activity does not support client certificates, but you should be able to do it with a custom activity. I'm told PostMan has a way to export C# code directly, so it could be quite easy.

https://answers.laserfiche.com/questions/172916/Certificate-authentication-in-HTTP-Web-Request-activity

1 0
replied on July 26, 2022 Show version history

They don't want to pass you a key on initial connection it seems, this way a listener doesn't grab a copy of it, although every other web service in existence is OK with passing you the key when you make the connection. I am also interested in what the solution for this is as we have multiple clients getting ready to hook up with ADP.

I thought TLS had a solution so that passing the key could be done in a way that was fully secure, allowing anyone anytime to contact a web service and obtain a key that could decrypt the data at the endpoint without anyone listening to their traffic getting a copy of the key themselves.

0 0
replied on November 15, 2022

The contents of the request are indeed protected by the TLS connection. TLS offers two main benefits: encryption and authentication. What the client certificate does is allow the server to authenticate the client side of the connection in much the same way that the server certificate allows the client to authenticate the server. There are other ways to provide authentication, but this method is nice in that it's leveraging the TLS standard and functionality already present in their software stack instead of inventing something new at the application layer.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.