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



Best practice for network design to host Forms securely when available to the public Internet

posted on November 14 Show version history

We are getting ready to migrate to new servers for self-hosted Laserfiche, and are re-examining our network architecture in the process. Our installation includes a Forms server that runs Public Portal and is accessible from the Internet.

We are investigating the best network architecture to secure Laserfiche Forms while making it accessible from the Internet.

I found the article published by Laserfiche entitled "Hosting Laserfiche Forms 11 in a Perimeter Network (DMZ)".

I also found a lecture by Samuel Carson, who I think is a Laserfiche employee, delivered at Laserfiche Empower 2023. In that called a DMZ "deceptively simple" and suggested that a reverse proxy architecture was the "Preferred method in most cases, especially with Forms". The title of the lecture is "Deploying Self Hosted Laserfiche Solutions" and I found it here:

I have two key questions:

  • What is the best practice as officially recommended by Laserfiche?
  • Does anyone (either from Laserfiche or not) have any counterpoint or cautions?
0 0
replied on November 16

Thank you Samuel,

Yes, I found your two-part lecture series very helpful. The second question is the easiest one for us--Forms is the product we want to make available on the Internet at this time.

The first question is less simple because we're re-thinking things to improve security.

I will take your take your suggestion to write up more details than would be appropriate here and send them through our VAR

Thank you very much for being willing to do this for us!


1 0
replied on November 15 Show version history

Hi Timothy,

I'm glad to hear you found my Empower talk and hope you found it informative. 

In most scenarios, the recommended configuration is to add a dedicated "external" Forms server within the internal domain network and use a public-facing reverse proxy to forward HTTPS/443 traffic to that server, as shown in this example diagram from the presentation:

To configure the "external" Forms server, you follow the Standard configuration instructions in the usual "Configuring Forms 11 in a DMZ" white paper, with the significant exception that you should not modify the SecurityMode anywhere. Because the "external" Forms server is on the same domain network, it can leverage all of the built-in/automatic AD-based security and encryption mechanisms.

Why have a separate server at all? Two main reasons.

  1. Limits security "blast radius"
  2. Allows for external-facing customizations you may not want to apply to the Forms instance(s) your internal users go to, including but not limited to different DNS names, authentication paths, etc.

Still, there are potentially reasons to deviate from that design. Have you gone through and answered the questions in the External Access Use Cases section of the presentation? If you can provide answers to the first two sets of questions, I can provide more tailored guidance. Any "counterpoint or cautions" would generally be in context to the use case.

If you don't want to post those responses publicly for whatever reason, please send them to your Solution Provider and request they send them along to the Laserfiche Presales team with a reference to this Answers post. That'll make it to me.

I'll reproduce the questions below for reference:

External Access Use Case Objectives

What are you trying to do?

  • Provide unauthenticated access to public forms and documents?
  • Provide vendors an authenticated portal to handle form submissions?
  • Provide students access to forms?
  • Provide general access to remote employees?
    • Almost always a bad reason, figure out a VPN solution

Use this information to answer three critical questions

First question(s)

  • Will users be Authenticated, Unauthenticated, or a mix?
  • If Authenticated:
    • How will they authenticate?
      • Laserfiche (LFDS) users?
    • SAML users?
    • How will they be provisioned and licensed?
      • Laserfiche (LFDS) users
        • Roll your own manual or programmatic provisioning process
      • SAML users
        • Just-In-Time (JIT) / Self-Registration
      • SCIM

Second question

  • Which Laserfiche components are involved?:
    • Forms / Forms Portal
    • WebLink
    • Web Client
    • Directory Server WebSTS
      • LFDSSTS = login page
      • Never directly externally expose /LFDS Web Admin itself
    • DocuSign Connector
    • API Server (new)

Third question 
(this is what you're trying to answer, and can depend on responses to the prior questions)

  • Reverse Proxy or DMZ server(s) as network access method?
    • Reverse proxy can be layer 4 (TCP) or layer 7 (HTTP)
      • Preferred method in most cases, especially with Forms
        • Greatly minimizes required firewall holes
    • If pointing at same servers for internal use, requires “double-sided” DNS
      • Be aware of security considerations; often better to use a separate “external” server
    • If load balancing, enable session affinity (“sticky sessions”)
      • Client IP-based affinity usually ideal, otherwise cookie-based
  • DMZ servers
    • Deceptively simple.
3 0
replied on November 16

Hi Sam, this is really interesting and not eh way that our org has our Forms set up for public use. 

Would it be appropriate to mirror this for weblink as well?

In your example the "public' forms server is inside the network would that allow more control for the 'Public'  user? Could I leverage having the main instance inside the firewall to allow for more public accessed forms that are also NOT available outside?

 I doubt that I am explaining my second point appropriately... I have 2 Forms servers, the main one, with the 'Public' user in the DMZ, but a second one inside the firewall, but this does not allow for any 'Public' users and everyone needs to have a LF license to enter the forms. 

If I rearchitected to your model would that allow me to leverage that public user for internal and outside forms better?



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

Sign in to reply to this post.