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

Question

Question

STS-enabled Web Client not redirecting to repository

Web Client Directory Server Version 10
Updated May 27, 2020
asked on May 25, 2020 • Show version history

Hi,

We're trying to use STS for authentication, and started by testing it with Web Client (10.3).  Our general infrastructure setup is as follows:

Server 1 = Laserfiche Server + repository
Server 2 = Web Client
Server 3 = Directory Server

In the Web Client configuration page, we have the following settings:

  • Connection tab: connection option for repository is set to "Prompt for credentials to <our domain>", SSL enabled.
  • Services tab: Laserfiche web client Host URL is set to the https://Web_Client_FQDN/laserfiche.  Prior to enabling STS, we are able to log in and access Web Client via this same URL
  • Services tab: Directory Server enabled, STS URL is https://Directory_Server_FQDN/LFDSSTS, "only sign in with SSO" is checked

 

We restarted IIS, then attempt to access Web Client using the same https://Web_Client_FQDN/laserfiche indicated above.  It seems to log me in successfully, but redirects me to the following URL showing a blank page:

  • https://Web_Client_FQDN/laserfiche/LFDS/Login.aspx?repo=&destPage=%2f

 

From the looks of this, it's not passing the repository name properly.  If I manually specify the repository after repo= (and get rid of &destPage=%2f), Web Client loads successfully.

Have we missed defining the repository somewhere, or is this a sign that STS is not actually working?  Any help is appreciated!

Thanks,
Eric

0 0

Replies

replied on May 26, 2020

Upon further testing, it appears that any valid domain users can sign in successfully, but they would also get the blank page of https://Web_Client_FQDN/laserfiche/LFDS/Login.aspx?repo=&destPage=%2f.

This means STS is unable to differentiate between authorized domain users (thus letting them into Web Client) and unauthorized domain users.  We must have misconfigured STS somewhere.  Any help would be appreciated.

0 0
View 6 previous replies
replied on May 26, 2020

Hi Eric, when you try to visit https://Web_Client_FQDN/laserfiche/ and land on the STS login page, what is the URL of that page in the browser? Be sure to sanitize the FQDNs (there will be several) in that URL if needed.

0 0
replied on May 26, 2020
0 0
replied on May 26, 2020

It looks like Web Client isn't specifying a repo when it sends the user to STS. My first thought is to make sure a default repo is specified, and try turning off "Only use SSO" to see if that gets you anywhere. Besides that I recommend having your SP open a support case so we can gather some more information.

0 0
replied on May 27, 2020 • Show version history

We only have one repo available via Web Client, so it was already selected as the default repo.

Going to slip in one more question.  I came across the STS Claims Testing Page section in the LF Admin Guide.  It says to navigate to https://STShostname.SampleDomain.com/LFDSSTS/claimstest after signing into an LF app via Directory Server.

I tried this on the Web Client server and got a generic "An error has occurred" message.

I then repeated this test on the Directory Server itself, and got a more detailed error message which I cannot decipher (see attached).  Could this be an indication that STS is not actually setup properly, thus leading to the initial problem?

I've been following the Configuring Single Sign-On for Laserfiche Web Products white paper, in particular configuring Directory Server and STS on the same machine.  I wonder if there's something more appropriate I should be using?

STS Claims Test error.png
STS Claims Test error.png (45.44 KB)
Download
0 0
replied on May 27, 2020

What version of LFDS / STS are you using?

0 0
replied on May 27, 2020

We're on 10.3.0.

0 0
replied on May 27, 2020

Ah okay, the claims test feature is not exposed for versions prior to LFDS 10.4.3 (I'll make sure that documentation page gets updated). I believe you should be able to enable it by adding this key to STS's Web.config under "appSettings"

<add key="EnableClaimsTest" value="true" />

 

1 0
replied on May 27, 2020

Thanks Chase, the Claims Test is working now on both servers.

One last question, since we have STS and Directory Server running on the same machine, is it even necessary to run STSEndpointUtility.exe (on Directory Server) and/or EndpointUtility.exe (on Web Client server)?  Also, SPNs and Kerberos Delegation won't be necessary with this setup either, right?

FYI the purpose of getting STS working is to move away from using Kerberos Delegation, since we weren't able to get constrained Kerberos Delegation (as required by our organization) working.  Right now we're using unconstrained Kerberos Delegation but are on the clock to stop doing so.

0 0
replied on May 27, 2020

The STS endpoint utility defaults should work fine if it is on the same machine as LFDS. For Web Client you should be good with defaults as well unless the two machines are on different domains without a trust. I don't believe you'll need to do any Kerberos configuration if LFDS and STS are on the same machine.

0 0
replied on May 27, 2020

The STS endpoint utility defaults should work fine if it is on the same machine as LFDS. For Web Client you should be good with defaults as well unless the two machines are on different domains without a trust. I don't believe you'll need to do any Kerberos configuration if LFDS and STS are on the same machine.

You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...