Feature Request: Compatibility of Snapshot with LFSSTS and LFDS

replied on September 30, 2019

Hi Ben,

Snapshot must connect to Laserfiche Server (LFS) - think of it as part of the Laserfiche Windows Client for networking purposes. It cannot connect to the Web Client instead, though we have heard that capability as a feature request before.

Presumably "disable all ports into LFS" means "disable any connections from sources not explicitly whitelisted", as Web Client, Workflow Server, etc. all need a connection to LFS.

Is this Laserfiche Server instance otherwise exposed to the public internet? What specific security concern are you seeking to address by blocking 443? Most organizations I've worked with are primarily concerned with ensuring that traffic only goes over 443/HTTPS and that unencrypted traffic over 80 is blocked.

0 0

View 3 previous replies

replied on September 30, 2019 • Show version history

Hi Samuel,

Rather than go into detail about the network and various subnets, I'll try asking a different way. Happy to detail the network a bit more if you need.

Consider the secure scenario that Laserfiche document in their deployment guide, where the Web Client server and LFSSTS service is on a server in the DMZ, for external access, and LFS and LFDS are internal.

In this scenario, what is the secure method to make Snapshot available, without exposing the LFS server? I don't believe there currently is a method.

I had temporarily enabled port forwarding on the firewall for port 443 on the LFS server. Obviously, this isn't a good idea, which is why I need to close it down as there should be no external access to this server; Port 80, 443, whitelisted or otherwise (except to the Web Client/LFSSTS server, in the DMZ, of course)

0 0

replied on September 30, 2019

Ben, gotcha. From a technical standpoint, you need port forwarding, a reverse proxy, or similar method of passing external traffic through to LFS. All of those are "exposing LFS" in some capacity.

I have a few investigative questions below. I'm not necessarily challenging your solution design; rather, looking to validate that we're trying to solve the right problem here. This information could also provide useful context on the potential value of a Snapshot-via-Web-Client feature.

What's the business case here and who are the users outside the network trying to use Snapshot?
It is relatively uncommon (in my experience) to have external users without VPN access need a locally installed component. How are they getting Snapshot on their machines in the first place?
Can these users Print-to-PDF (or similar) and upload through the DMZ Web Client instead? What functionality would Snapshot provide that other methods could not?

Cheers,

Sam

0 0

replied on September 30, 2019 • Show version history

Hi Sam,

Feel free to challenge.

1. For generating TIFFs from emails of receipts (the receipts are in the email body, not attachments) , primarily. The TIFFs are OCR'd and processed. I've thought about just saving the emails and extracting the texts but emails aren't as easy to view in mobile as TIFFs. Also as the solution is also used to process receipts captured by mobile cameras using Forms, all captured receipts (when using snapshot) have a consistent image format, without additional conversion in workflow.

2. Snapshot was installed on the client laptops as the solution was originally designed an internal only Avante 10.0 implementation. For sure a VPN would resolve the issue but given the security of LFSSTS, it would be great to use that.

3. Yes that would work but requires significantly more clicks. At the moment, snapshot has been configured with a profile to capture and save to the correct location. It's only being used for receipts.

-Ben

0 0

replied on September 30, 2019

Ah, that helps immensely. Interesting use case.

Here's how I would approach it:

1. If the customer has any existing VPN capabilities, look into adding these external users into a VPN/network security group with access to nothing other than LFS over 443. Eliminates any public-facing LFS ports. Very clean from the network security perspective so long as that VPN group is locked down tight.

2. Save emails in native format either via Outlook Integration or the Laserfiche Email Archive Service (EAS). With EAS and some clever Exchange transport rules you could potentially make the process 100% automatic for the users.

Have Workflow monitor for incoming .msg/.eml files however makes sense for the process. Have new email imports trigger a workflow that uses the third-party Aspose.Email library to convert and replace the email message with a TIFF rendering. Though Aspose.Email isn't free, it isn't too expensive in the grand scheme. I think you can get a 30 day trial to test it out first. I've worked with other Aspose libraries in the past and was quite happy with them.

0 0

replied on September 30, 2019

1. The VPN approach would mean setting up new infrastructure for a single process.

2. As I said about, I'd rather not go down the custom development and conversion route but agreed, it's probably the neater (though not most secure) route.

If I read between the lines, it sounds like Snapshot might be deprecated, rather than updated for LFSSTS. Is that possible? I hope not.

0 0

replied on October 1, 2019

1. Gotcha - hence "If the customer has any existing VPN capabilities". Likely doesn't make sense for a single process.

2. What security tradeoffs do you see? The approach I suggested goes entirely though either [Outlook Integration/Web Client/LFDSSTS] or Exchange/EAS, with no public routes to LFS.

Snapshot is not depreciated. As you're likely aware, Snapshot is part of the Laserfiche Windows Client installation package. It currently has the same LFS connection options as the Windows Client and Admin Console, the other main components bundled in.

I'll update our internal user story on Snapshot capabilities via Web Client with a link to this discussion so Dev has the info on your use case.

0 0

Question

Question

Feature Request: Compatibility of Snapshot with LFSSTS and LFDS

Replies

Sign in to reply to this post.