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

Question

Question

SAML Authentication using Multiple STS sites?

Laserfiche Directory Server Version 10
Updated June 22, 2020
asked on June 24, 2019

We have a client that we setup with SAML authentication a while back. We then deployed a secondary set of servers (DEV and PROD). When we did this, we noticed we could only get the products to authenticate through one STS site. We left it running through the PROD STS site. 

We are now at a point where we want to ensure these are 2 completely stand alone systems (other than DS). We have looked at all settings and there doesn't seem to be anything incorrect. 

It seems as this could be a limitation of SAML authentication for Laserfiche. Is this true?

We have no issue with the actual STS sites - they are running as they should with correct settings. The issue happens when we go to the DEV url, click sign in with Directory Server, then select the SAML button, then it asks for our Google account. At this moment, the URL changes from the DEV URL to the ACS URL (which happens to be the PROD STS Site Endpoint). It also then gives the error message (attached). 

I look forward to hearing if this can be done. Thanks 

ACS Error.PNG
ACS Error.PNG (3.58 KB)
Download
0 0

Answer

APPROVED ANSWER
replied on June 27, 2019 • Show version history

I took your setup back to the team, and they agree: this is most likely a limitation of SAML authentication with Laserfiche at this time.

They suggested the following workaround:

  • Create a second application profile in your SAML provider configuration for use with the dev environment
    • Ensure that you have unique endpoint URLs for each profile
    • Ensure that, as you noted, the dev ACS URL is used for the dev environment profile
  • Create a second SAML identity provider in LFDS, pointing to this second application profile under SAML endpoint

 

This will result in two SAML login buttons appearing on each STS/login page. To handle that for now, I have two recommendations:

  1. Label them clearly using the option we provide to customize the login button text
  2. Add customization to the login page to hide the button for the Dev SAML provider
    • I know customers and Solution Providers have done this before, though I don't have the code at hand

 

On our roadmap is the ability to specify which authentication options are used on each STS, so that would provide option (2) out of the box. I'll link this post to the feature on our backlog so I can keep your use case in mind + add important updates.

Thank you for sharing the details of your environment, and let me know if you have further questions.

0 0

Replies

replied on June 24, 2019

I'm not sure I understand your current setup. Does the following sound accurate?

  1. Production application (e.g., web client or Forms) pointing to production STS
  2. Separate installation of applications in dev pointing to dev STS
  3. All applications and STS pointing to same LFDS
  4. One SAML provider that is used for both dev and production

 

If not, could you tell me how your setup differs?

If that is correct, can you tell me more about the login flow? For example, you say "they go to the DEV URL" --- are they navigating directly to the STS, or are they attempting to go to a specific application (e.g., a document in Web Access, their inbox in Forms).

0 0
replied on June 25, 2019 • Show version history

Hi Brianna, 

The way you described is how we'd 'like' to have it. Currently, both the DEV applications and the production applications have to use the same STS site or we get the error described above. The URL I was referring to is a friendly URL, but still the proper login. (example: https://prodserver/forms & https://devserver/forms would both get the login screen, get them to the google accounts, and then when google tries to authenticate the URL would change to the https://prodserver/LFDSSTS/saml2/sso even if they are on the https://devserver/forms. 

I'd be more than happy to provide a demo of the behaviour to you if you'd like on a remote session or I could take a video. 

Thanks for your help. 

0 0
APPROVED ANSWER
replied on June 27, 2019 • Show version history

I took your setup back to the team, and they agree: this is most likely a limitation of SAML authentication with Laserfiche at this time.

They suggested the following workaround:

  • Create a second application profile in your SAML provider configuration for use with the dev environment
    • Ensure that you have unique endpoint URLs for each profile
    • Ensure that, as you noted, the dev ACS URL is used for the dev environment profile
  • Create a second SAML identity provider in LFDS, pointing to this second application profile under SAML endpoint

 

This will result in two SAML login buttons appearing on each STS/login page. To handle that for now, I have two recommendations:

  1. Label them clearly using the option we provide to customize the login button text
  2. Add customization to the login page to hide the button for the Dev SAML provider
    • I know customers and Solution Providers have done this before, though I don't have the code at hand

 

On our roadmap is the ability to specify which authentication options are used on each STS, so that would provide option (2) out of the box. I'll link this post to the feature on our backlog so I can keep your use case in mind + add important updates.

Thank you for sharing the details of your environment, and let me know if you have further questions.

0 0
replied on July 2, 2019

Thanks Brianna, we will run with your workaround. I think both buttons there will be okay since we can label them in LFDS, but in seeing another thread that you were commenting on (https://answers.laserfiche.com/questions/148272/Web-access-login-page-customisation#148863) I too would be interested for this customer to hide this option as they are not using the Windows Authentication either. 

Thanks

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

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...