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

Question

Question

How do we setup an IdP and STS site for Okta in LFDS, so that the SAML button works on the LFDS landing page?

Directory Server
Updated April 3, 2020
asked on March 26, 2020

We've setup an Okta SAML chicklet for Forms 10.4.x. The Okta SAML assertion is passed to our LFDS server, and then LFDS parses the assertion against our Okta - Laserfiche Forms IdP. The Okta - Laserfiche Forms IdP proxies the assertion against our Active Directory provider using SID, so the user can login. This works great!

On the LFDS landing page, however, we can't seem to configure the SAML button to direct the user back to Okta to re-auth? We're thinking this is a combination of settings in the Okta - Laserfiche Forms IdP and an STS site, but are unsure how to set this up? Has anybody done this, or point us in the right direction?

It's interesting because Okta provides a deep link for auth'ing against an App (something of the format: https://********.okta.com/home/*********_laserficheformsdevsso_1/0oa1goh1ea1UBXbPe1d8/aln1goh7r1egoEBkA1d8). So this would work if I could make the SAML button use the deep link.

Any help would be appreciated, thanks!

0 0

Replies

replied on March 27, 2020 • Show version history

hello! Can you elaborate about the expected user flow when you say "direct back to Okta to re-auth"? 

Are you referring to:

1. Users navigating directly to the LFDS login page (e.g., https://yourLFDs.com/LFDSSTS) and attempting to login there, rather than first navigating to a Laserfiche application?

2. Asking that LFDS require users to go back to Okta even if there's an active Okta session?

3. Adding LFDS to the applications list in Okta so that users can navigate from the Okta home page?

0 0
View 2 previous replies
replied on March 27, 2020

Hi Brianna,

We are looking to perform something like 2. Ultimately, rather than having the user start or end at the LFDS landing page, we'd like them to go through Okta to access a Laserfiche web application. We'd like LFDS to be transparent if possible. We currently have our environment setup this way, and are hoping we can keep the login structure the same if we fully switch to SSO.

0 0
replied on March 30, 2020 • Show version history

Hi Joshua,

What you described to me sounds more like #3, so I want to further clarify. #2 was describing forced reauthentication (forceAuthn), which means that no matter how users get to Laserfiche and no matter whether or not they have already signed in through Okta, they must return to Okta where Okta re-authenticates the user.

Example user flow A (force reauthentication when the user attempts to access Laserfiche):

  1. User visits some other application that authenticates with Okta and signs in to Okta at that time
  2. User navigates to Laserfiche (repository or forms)
  3. Laserfiche redirects the user back to Okta and requires them to re-enter their authentication information before sending the user back to Laserfiche
  4. User ends up at original Laserfiche destination after authentication is complete.

 

Example user flow B (initiating from an Okta-based landing page):

  1. User goes to yourcompany.okta.com
  2. User sees list of applications
  3. User clicks on "Laserfiche" and goes to somewhere in Laserfiche
    1. Laserfiche destination is defined when the admin is configuring Laserfiche as an Okta application
    2. For example, the forms inbox or a main shared repository

 

 

If neither of this is what you mean, can you describe in similar detail what you expect the user to see and do? SAML is a very flexible protocol, so there are many different ways companies choose to set up SAML authentication.

0 0
replied on March 30, 2020

Hi Brianna,

I am going to use Forms to describe what we'd like:

  1. If a user logs in through Okta, we'd like them to be able to click on the Forms chicklet in our Okta portal, and be directed to Forms.
    • We have this configuration working by passing the Okta SAML assertion to LFDS, LFDS parses the assertion, and then LFDS passes the appropriate information to Forms.
  2. If a user clicks a Forms link from their email, we'd like them to be directed to Okta to auth, if necessary, and then go to Forms. We'd like information contained in the Forms link preserved (e.g., if the Forms link is a direct link, we'd like the user to login and be taken directly to the appropriate Form). If possible, we'd like to make the LFDS landing page transparent.
    • In our current configuration, the user is presented with the LFDS landing page, and a SAML login button. We haven't been able to get the SAML login button configured correctly, hence the questions.
  3. When a user logs out of Forms, we'd like them to go back to the Okta portal page, rather than the LFDS landing page.
1 0
replied on March 30, 2020 • Show version history

Thank you --- that cleared a lot of things up for me!

Scenario #1 (user navigates from the Okta portal) was not the focus of our current implementation, so while I know that customers and resellers have made it work, it's possible that the settings to make this scenario work is causing issues for Scenario #2. I will see if I can get suggestions from folks who have worked with this setup in production environments.

 

Regarding Scenario #2 (user clicks link in their email):

The expected flow in this case is:

  1. user clicks link to a specific Laserfiche application/document/form in email
  2. user is automatically redirected to LFDS
  3. user clicks on the SAML login button
    1. edit: we don't currently support removing the button click, thought it is on our backlog.
    2. I know resellers and customers have implemented the auto-button click themselves if you want to go that route
  4. user is prompted for authentication by the SAML provider if they don't have a current valid session
  5. user is automatically redirected back to the LFDS login page, which in turn automatically redirects them to the original destination link link

This the scenario we designed for, so it should definitely be working. You may want to request that your reseller open a support case.

It would be helpful to know what type of issues you are running into --- is the user getting an error? Are they being authenticated but not redirected to their original destination?

We do have an updated troubleshooting section for LFDS, including instructions on checking for the SAML token.

Finally, Scenario #3 (user is returned to the Okta portal after logout) is not possible at this time, but I've put it in our potential features backlog and referenced this post.

1 0
replied on April 3, 2020

Thank you, Brianna!

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

Sign in to reply to this post.

Details
Related Posts
Loading ...