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

Question

Question

How can we setup SAML for production AND development servers

Directory Server Forms Web Client
Updated October 18, 2018
asked on October 12, 2018

We setup SAML for a customer and everything is working fine for the dev servers (forms, Web Access). We then went to setup the production servers and installed a second STS instance on Prod Web Server, did all of the certificates, etc. 

We added the Prod server as a 2nd hostname under the "STS Sites" in LFDS, but we were getting a looping when clicking to sign in with SAML (it would just reload the page basically). 

We are able to access both Dev and Prod repositories due to the ability to add both in the Web Access Configuration. The real issue is now accessing both Forms servers using SAML accounts. 

It seems like we can use SAML for either Dev OR Prod, but not both due to the "Entity ID" in the general tab of LFDS Settings. 

Is there a way to work around this or are we stuck with one or the other?

 

I hope I've explained it well enough for someone to voice their opinion. 

 

Thanks

1 0

Replies

replied on October 15, 2018

Hi Shaun,

 

After you set up the second STS site in LFDS, did you re-generate the SAML provider metadata file and exchange it with SAML idp again?

 

Yining

0 0
replied on October 15, 2018

Hi Yining, 

 

Yes we did. We did change the "Default Landing Page" on the SAML Login Configuration on the General tab of settings to the Production URL with /LFDSSTS, rather than what was there (Development URL with /LFDSSTS)

 

Without this changed, I felt it was trying to take us to the development server. Does this matter?

0 0
replied on October 15, 2018 • Show version history

Hi Shaun,

The "Default Landing Page" is not required in most scenarios, since we use the RelayState parameter with original destination URL to pass the final location around.

However, some SAML providers do not preserve the RelayState, leaving LFDS with no information as to where the user should go. For that case, we provide the Default Landing Page option.

Since it was working for Web Access, RelayState is likely preserved by your SAML provider, and as such, you should not need the Default Landing Page.

Example of how SAML authentication works with RelayState:

  1. User navigates to LF page that requires authentication (Form, document, etc.)
  2. User is redirected to LFDS SSO page
  3. User clicks SAML authentication button
  4. User is sent to SAML provider's login page, including a URL parameter for the RelayState
    1. For LF, the RelayState will be a URL to the original page the user tried to visit
  5. When authentication is finished and the user is redirected back to the LFDS SSO page, the SAML provider passes through the original RelayState parameter
  6. LFDS SSO authenticates the user into the Laserfiche system, and then sends the user to the URL specified in the RelayState

 

If you do need to use the Default Landing page, it should be something like your Forms inbox or a splash page you created to let users choose from a variety of Laserfiche destinations.

If there is no RelayState found and /LFDSSTS is the default landing page, it will do exactly as you described: send the users back to the login page (located at /LFDSSTS). At this point, LFDS does not have any information as to where the user is trying to go.

Note also that if you start on the login page, /LFDSSTS (rather than from a link to a form, document, etc.), you will be redirected back to the login page even if RelayState is implemented, since that is the only URL LFDS has to work with.

1 0
replied on October 18, 2018 • Show version history

Hi Brianna, 

Sorry for the delay in responding, I had to verify that Google was indeed preserving the RelayState, which it is.

I was able to get things working, here's what I did: 

I removed the default landing page - since the SAML provider 'Google' preserves the RelayState, there is no need for this. Tried logging in, same issue. 

I then went into the DEV Forms Configuration and changed the Directory Server STS URL from the DEV STS site URL to the PROD STS site URL. - This fixed the issue. 

 

Summary: Both DEV and PROD Forms servers are pointing to the PROD STS URL. 

 

Question: Is it possible that maybe SAML does not support more than "1" STS site for authentication?

 

Either way, we are more than happy to just use the Prod STS URL for both DEV and Prod Forms. 

 

Thanks for all of your help with this!! I'm sure this will help others in the future with this setup.  

1 0
replied on October 15, 2018 • Show version history

Some clarifying questions about your setup:

  1. Are your Forms installations completely separate, or do they share a routing server?
  2. Are you using two different SAML providers, or just one?
  3. When you say that Web Access is "working", do you mean that:
    1. Dev Web Access takes you to the dev STS page, and after login you are taken back to dev Web Access
    2. Likewise, production Web Access takes you to the production STS page, and after login you are taken back to the production Web Access

 

Can you also describe the steps you take and what you see?

For example, if it was working you might say:

  1. User goes to URL for a form on your production Forms server
  2. User is taken to https://yourProdSTSMachine.com/LFDSSTS/Login?originalPathAndQuery=somereallylongURLencodedparameters
  3. User clicks on SAML authentication button
  4. User successfully authenticates through SAML provider
  5. User redirected back to the STS page, which redirects them to their original forms URL
0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...