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

Question

Question

Prevent a user account from logging in to the repository by any means other than the API?

Laserfiche API
Updated June 28, 2023
asked on June 26, 2023

Similar to how we can setup both Workflow and Import Agent, is there any way we can prevent the API user account from being used to access the repository normally through either the Windows Client or Web Access.

Being able to only accept traffic from specific hosts within the API config does not add any additional security if the account can be used to login through the primary applications as well.

0 0

Answer

SELECTED ANSWER
replied on June 28, 2023

There is nothing actively in-place preventing users specified in Workflow, Forms or Import Agent from logging in through the clients. In United systems, these users can log in. In Avante and Rio, they are only prevented from logging in by the lack of a named user license and Manage Trustees privilege. If you grant them either one, they'll be able to log in. Obviously, granting them a named user license is a waste of a license, but granting them Manage Trustees may be desired in scenarios where Workflow would do trustee administrations tasks.

The inability to log in through the desktop and web client is not a feature and should not be relied on for security purposes. Furthermore, if the credentials leak, the inability to log in through the client apps is not a limiting factor in the potential damage that can be inflicted. 

0 0

Replies

replied on June 27, 2023

Hi Chad,

I'm curious about your use-case. With my customers, the API account has very limited access to a single folder. And the credentials are tightly controlled. You could even post instructions to that folder for the Workflow to execute on behalf of the API.

Alternatively, Integrator Licenses can only be used through the API. 

1 0
replied on June 27, 2023

This is a good idea, we could have an incoming folder and a workflow could move the documents to the live folders. As long as the API user does not require privileges to function.

1 0
replied on June 26, 2023

Hi Chad,

 

It may help to understand your use-case a bit more.  What are you trying to accomplish with the API?  Are you using the API to make requests on-behalf of your users, or is it more of a service application where you could create a dedicated account for just API usage?

 

0 0
View 4 previous replies
replied on June 27, 2023

It would be as a service, to transfer invoices via Workflow from Cloud to an On-Prem repository.

There is an option to restrict calls to the API down to a specific source, in the event someone leaks the API creds. Although if you could simply login through Web Client then using the credentials to get in is even easier.

With Import Agent and Workflow, if someone obtained the credentials for the service user, they could only connect via those services, which at the very least makes it much more obscure compared with being able to simply login and if the Workflow ports were restricted to the workflow host source it would be impossible to make use of the credentials to get in to the repository in any way.

0 0
replied on June 27, 2023

Hi Chad,
To transfer a document from a Laserfiche Cloud repository to a Self-Hosted repository you could use the following pipeline:

  1. Start a Laserfiche Workflow in Cloud that
  2. Gets a Self-Hosted API Access Token using Web Request Rule (new Web Request Rule feature scheduled for 2023-07 allows for storing username and password securely in web request rule)
  3. Use Access Token to import a document using Web Request Rule (to self-hosted API Server)
     
0 0
replied on June 28, 2023

Hi Paolo

The web request rule to request an access token requires an API service account, this is the service account that can also login to the repository through normal means if someone had the credentials. I am looking for a way to prevent this account from being able to login through normal means and only be able to be used to generate access tokens. Similar to how we do workflow and import agent connections, there is a service user, but it can not login to the repository through any normal means.

0 0
replied on June 28, 2023

Chad,

The credentials for the API account should be protected, like any other account.  If protected, I don't see how anyone could use that account to access the repository unless the credentials were shared.

1 0
replied on June 28, 2023

That is true but I am posting to see if we can prevent the user account from being able to login in the event the credentials were leaked. This is common practice for service accounts.

We do this with the Forms Save to Repo account, Workflow, Import Agent, and Audit service accounts and looking for a way to do it with the API account as well is all.

0 0
SELECTED ANSWER
replied on June 28, 2023

There is nothing actively in-place preventing users specified in Workflow, Forms or Import Agent from logging in through the clients. In United systems, these users can log in. In Avante and Rio, they are only prevented from logging in by the lack of a named user license and Manage Trustees privilege. If you grant them either one, they'll be able to log in. Obviously, granting them a named user license is a waste of a license, but granting them Manage Trustees may be desired in scenarios where Workflow would do trustee administrations tasks.

The inability to log in through the desktop and web client is not a feature and should not be relied on for security purposes. Furthermore, if the credentials leak, the inability to log in through the client apps is not a limiting factor in the potential damage that can be inflicted. 

0 0
replied on June 28, 2023

Got it, I wanted to enable it if it was possible since anyone in the world can attempt to login to WA, but the API can be locked down to accept only connections from certain hosts and in some cases may only be used internally.

Window has a feature that prevents accounts from being able to login to a server or workstation in case your only using it to connect services. It would be a similar idea. No reason for anyone to ever login as this account, or any other accounts that simply connect services together.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...