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

Question

Question

Sailpoint Integration

Integrations
Updated March 2, 2023
asked on October 23, 2022 • Show version history

Hi,

Our organization is implementing the Sailpoint application in order to centralize the Authentication and Authorization of users to all applications. I would like to know if anyone has had this experience and how they went about integrating laserfiche and Sailpoint if at all it's is feasible given the different levels of privileges and rights and entity access rights within laserfiche.

Mark

0 0

Replies

replied on November 30, 2022

We use Sailepoint as our SSO at University of San Francisco. It works fine, but Laserfiche is not exactly easy to set up with SAML. I've had experience with Shibboleth (what Sailpoint uses) at a few different institutions, and was never easy. Laserfiche was built from the start with Active Directory, and while SAML support is better it's very much 'bolted onto the side.' 

The biggest weakness in using SAML instead of AD is there is no automatic 'tombstone' of inactive accounts with SAML. We had to use workflows with a few custom scripts to feed a list of inactive users into LFDS to remove licenses from accounts that are no longer active.

Also, if your SSO team feeds Laserfiche email address for the LF username it will append the domain with an underscore replacing the @ symbol. This presented a huge issue with integrations from other systems that had just the username to assign Forms tasks. 

Laserfiche had a username as smith_usfca.edu, but when we pull that persons name from another system and try to use that to assign a forms task (Lookup Rule in forms) it comes in as just 'smith' and the user task assignment fails. 

1 0
replied on November 30, 2022

Hi Glen,

LFDS will soon support SCIM 2.0 for user lifecycle/license management. SailPoint appears to support SCIM 2.0. That might help your org with the inactive account cleanup piece.

My understanding of the reason Laserfiche performs that character substitution in SAML usernames is that the "@" symbol is used explicitly to identify AD and LDAP UPN-formatted usernames (at least at the LFDS authentication stage). An "@" in a username tells LFDS "this is an AD or LDAP account, and the part after the @ is the domain identifier".

While not ideal vs it automagically working, you can likely use a hidden Forms field with JavaScript auto-appends "_usfca.edu" to the result of the lookup rule (call the variable UsernameWithDomain or something) and then use that value for the subsequent user task assignment instead. The JavaScript for that should be relatively straightforward.

From what you describe, you'd have the same issue if Laserfiche had the username as smith@usfca.edu instead. Laserfiche requires usernames be globally unique, so if you want to do task assignment by username, it has to be an exact match. Imagine you had both smith@usfca.edu and smith@example.com as users - how would Forms reconcile a task assignment to "smith"? If there's only a single SAML IdP and you have requirements to perform user lookups against other systems that have only the domain-less username, it would be best for the IdP to pass Laserfiche that attribute ("smith") as the SAML NameID rather than the full email address/UPN.

0 0
replied on October 24, 2022

Hi Mark,

In short, yes. Sailpoint is a widely used SAML 2.0 provider and I'm not aware of any issues integrating it with Laserfiche.

The specifics of how you go about this depend on a few things, so let's start with those.

  1. Self-hosted Laserfiche or Laserfiche Cloud?
  2. If Self-hosted, are you currently using AD users?
  3. If currently using AD users, will AD be the backing IDP for Sailpoint?
  4. If AD users are sync'd to Sailpoint, is it possible to sync the AD users Group SIDs so they can be send in a SAML group claim? 
0 0
View 6 previous replies
replied on October 25, 2022

Hi Samuel,

Thanks for the info.

1. The laserfiche is self-hosted and

2. are using Active Directory.

3. The AD user will be the the IDP for Sailpoint

I am not sure I understand the second part of question 4 regarding group claim. Would you kindly elaborate?

 

0 0
replied on October 25, 2022 • Show version history

Got it. In this scenario, you'll want to:

  1. Set up Sailpoint as a SAML Identity Provider in LFDS
  2. Configure AD as a Linked Identity Provider in Laserfiche Directory Server for Sailpoint

This setup will result in Sailpoint SAML logins being mapped to AD users. It has a major benefit in that you can continue using Active Directory Group Synchronization for user license provisioning, something that is otherwise a massive pain with "SAML users". AD Group Sync provisioning is entirely separate from authentication.

However. LFDS cannot look up the AD group membership of a user from an AD-linked SAML login. The Linked Identity Provider documentation notes:

All AD or LDAP groups must be included on the SAML token or their membership will be ignored.

The documentation further notes:

The group value must be either AD SID or LDAP Distinguished Name (DN). Azure AD has a minimum requirement for including the AD SID and does not support the LDAP DN.

My understanding is that the requirement for group values in the groups claim to be in AD SID format applied to linked Active Directory IDPs in general and not is specific to Azure AD as a SAML provider.

If you want to use AD groups for security/permissions in any Laserfiche applications, they need to be sent in SID format in the Sailpoint SAML token's group claim.

0 0
replied on December 11, 2022

Hi Samuel,

I followed your setup suggestions but I was not successful. I was able to set up (step 1) sailpoint as a SAML IDP. But whenever I tried to log in to the laserfiche as a test, I was expecting to be directed to Sailpoint but it asked for AD  credentials. 

I decided to check step 2 but unfortunately I did not get the tab to provide a linked Identity Provider for Sailpoint. I thought maybe the LFDS version is the cause. I am using LSDS ver 10.3, does the version matter?

The other question I have is how we handle the thick client so as to be able to use the Sailpoint.

Regards,

Mark

0 0
replied on December 12, 2022

Hi Mark,

Yes, version matters. You will need to upgrade to Laserfiche 11 for this all to work. In addition to many general SAML-related fixes and enhancements, the Linked Providers feature is not present in older (pre-10.4.2?) versions of LFDS. The Laserfiche Windows (thick) Client gained the ability to use LFDS, and thus SAML, authentication, in version 11.

You and your customer should also be aware that per the updated Laserfiche Support Lifecycle Policy, the End of Support date for Laserfiche 10.3 is December 31, 2022. An upgrade is certainly in order, and we'd definitely recommend going to version 11 rather than 10.4.x.

If the LFDS login page is automatically prompting you for AD credentials, the LFDSSTS "Always use Windows Authentication" configuration setting is almost certainly enabled. See the "Sign-in Page Customizations" section of Configuring Laserfiche Directory Server for Enabling Single Sign-on for Laserfiche 10 and Laserfiche 11 Web Products.

You may not want to disable this setting in a Production environment while you're still testing as it will change the login experience for end users. You should be able to get to the LFDSSTS login page options (where your registered SAML IdP should appear, if enabled) by either selecting "Cancel" on the automatic Win Auth (AD) login prompt or respond to the prompt to log in, then immediately logging out (which returns you to the login page without triggering automatic Win Auth).

Hope that helps,

Sam

1 0
replied on December 13, 2022

I'll second this. SAML support in LFDS 11 is far superior to 10.x

1 0
replied on February 22, 2023 • Show version history

Hi,

Thanks for the information. The system was upgraded to Version 11. Took some time but well and good. So we revisited the configuration and finished the SAML configuration. But there is an issue whereby when we try and log in to the web client, when we click the SAML button at the login page, it opens the Saml sign in page where we key in the credentials, on doing that there is an error page that is displayed saying that the information we are about to submit is not secure. We then click on "Send Anyway". The system takes us back to the laserfiche sign in page. However the response received on PingSSO side is a successful SAML response. Please advise what needs to be configured to fix this. 

Mark

0 0
replied on February 28, 2023

Hi Mark,

This Google Support post I found suggests that Chrome throws that warning on form posts to http:// rather than https:// URLs.

This suggests to me that the LFDSSTS SAML endpoint URL configured in LFDS and/or the SAML IdP (Ping) is not https. The value in the STS Site config screenshot below is what's written into the LFDS SP Metadata file you likely uploaded to the Ping SAML IdP. You may have manually entered the STS SAML endpoint value into Ping instead.

It's still working because LFDS is doing an automatic http -> https redirect, but the browser is throwing the warning because the target URL is http. You likely don't see anything in the Ping logs because this appears to be a browser error, not a Ping error.

0 0
replied on March 1, 2023

Hi Samuel,

I get the https issue. My main concern is not the error itself but the fact that in the Ping logs, it is said to have a successful connection whereas in Laserfiche it returns to the login page and we never get to log into Laserfiche. Please advise

Regards,

Mark

0 0
replied on March 2, 2023

Ah, I misunderstood "The system takes us back to the laserfiche sign in page" as meaning "after clicking through the Chrome error, we're successfully redirected back to the LFDS STS page to complete the SAML handshake".

From what you're describing, Ping logs that it issues a valid SAML response to the browser along with the redirect to LFDSSTS. Then you get a Chrome security error in the middle due to the http(s) issue. Clicking through takes you back to LFDSSTS, but the SAML response seems to have been lost.

You should fix the http(s) issue first. Chrome is potentially removing the SAML response data before allowing you to continue onto non-https LFDSSTS in an effort to protect the user. I do suspect they're related. The behavior you've described would occur if the SAML response from Ping was completely missing by the time the user got back to LFDSSTS. If the SAML response was present, but there was something wrong with it, LFDS would throw an error.

If after you fix that the same issue occurs, please open a support case and reference this Answers post.

You should also check the LFDS event logs to see if there are any SAML-related backend errors logged that may not be surfaced in the UI.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...