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

Question

Question

SAML Auth via IDP called Classlink

Directory Server Version 11 Administration
Updated October 10, 2022
asked on September 13, 2022

Hello,

We have an customer in the Educational Sector, who is on the Subscription Model for LF.

They would like to utilize the SAML option and they are tied to an IDP called "Classlink"

I do not see any documentation that this is supported in LF, but wanted to check and see if anyone else has tried to implement this with any success.

Appreciate the feedback,

Jeff Curtis

0 0

Answer

SELECTED ANSWER
replied on September 13, 2022

Hi Chris,

While we do not officially test the LFDS SAML 2.0 integration with "ClassLink", I reviewed their SAML documentation and aside from two exceptions, didn't identify anything that would be an obvious compatibility issue.

Disclaimer: While LFDS broadly supports the general SAML 2.0 specification, some components are optional, and various service and identity providers can be subtly different and/or not expose all necessary configuration options. We make no specific guarantee that ClassLink will work as a SAML identity provider for LFDS. All guidance here, and any assistance from Laserfiche Support, is on a best-effort basis.

That said, your general steps would be as follows:

  1. Make sure you have LFDS configured as necessary to generate a working SP Metadata file. This mostly involves ensuring you have your STS Site registration(s) configured correctly. Please note that the "Hostname" part of the STS registration (last config filed) must have the machine's actual FQDN hostname and not an alias. The SAML endpoint URLs need to use the same base address(es) as you have configured for the LFDSSTS auth URLs in your LF web apps.
  2. Generate the SP Metadata file in LFDS, open it, copy the text contents, and paste them where indicated in the ClassLink SAML IDP config page.
  3. Configure NameID value/format as desired. This is the primary key that gets matched against the SAML users in LFDS.
  4. Configure attribute mapping as desired. You generally need first name, last name, display name, email, and groups claims.
  5. Save ClassLink config. Enter the IDP Metadata URL in the LFDS ClassLink SAML IDP config interface and pull it down. If the ClassLink signing cert is self-signed, you'll need to extract it from the metadata, save the cert file, and install it in the machine Trusted Root Certification Authorities store on the LFDS server. You can use this online tool to extract the signing cert: https://www.rcfed.com/SAMLWSFed/MetadataCertificateExtract
  6. Configure corresponding claim mappings for the attributes in LFDS. The values you enter here must match the attribute names in the ClassLink SAML token exactly. Use the SAML tracer extension or similar tool of your choice to view the SAML response body.
  7. After performing SAML auth to Laserfiche that at least appears to complete the auth handshake, go to https://yourlfdsstsurl.example.com/LFDSSTS/claimstest to view the contents of the LFDSSTS token. Make sure that it at minimum includes the user/nameID, email, and group attribute values you expect.

The above is general guidance based on looking at ClassLink's docs and has not been tested. Combine it with our existing SAML setup documentation for IdPs we do test with and ClassLink's own documentation.

Points of concern:

  1. Laserfiche's SAML SSO integration has a hard requirement for IdP SAML assertions to be signed with a cryptographic signature for the <saml:Assertion> block. While most SAML IdPs seem to do this by default/automatically, some other require it to be enabled. I do not see any mention of assertion signing on the ClassLink SAML documentation page or an option in any of the UI screenshots. Hopefully that means they do it automatically. Signing only the <samlp:Response> block is insufficient.

  2. The ClassLink SAML documentation page appears to discuss an "IDP-initiated" SAML flow where users select the app from some kind of ClassLink "app launcher". Laserfiche does not support a IDP-initiated SAML login flow. Users must perform an "SP-initiated" flow where they start by going to a Laserfiche web application URL like https://lf.example.com/Forms and are redirected to the SAML IdP. 

2 0
View 2 previous replies
replied on September 14, 2022

Thanks Sam

I will pass this along to the customer

Jeff

1 0
replied on September 15, 2022

You're welcome Jeff. Please do reply back with an update on if you get it working or not for the benefit of others.

0 0
replied on September 27, 2022

Hey Sam,

Couple of follow-up's after I met with customer:

1.  Generating the STS Site in LFDS produces a machine FQDN with .local. for Identity and SAML endpoints. Should the customer change the SAML endpoints to their external DNS (.org) and then use that metadata for Classlink.

2. Security- is 443 the port used for LFDS to talk with the IDP and vice versa...should there be other process enabled to lock this down more (NATing or Reverse Proxy). LFDS is installed on an internal machine

Appreciate the feedback,

Jeff Curtis

0 0
replied on September 27, 2022

Hey Jeff,

The two SAML endpoints should use the same base URL as the LFDSSTS auth redirects for Laserfiche web apps. The "SAML endpoint" field defines what's called the Assertion Consumer Service (ACS) URL, which is where the IDP's SAML response is sent by the browser. SAML IDPs (should) validate that SAML requests only come from and SAML responses are only sent to the ACS URL(s) in the SP metadata.

Something important to keep in mind is that the SAML IDP and LFDS/STS are never communicating directly with each other. The SAML request/response handshake happens entirely within the user's browser. Internal/external DNS for the ACS endpoint URL are irrelevant from a SAML protocol perspective.

If Laserfiche web apps are configured to redirect to "https://lf.example.com/LFDSSTS/" for auth, lf.example.com is what you need for the SAML endpoints as well. Like so:

The scenario where "internal vs external" can matter is if you have multiple STS sites that users access at different URLs. For example, an internal STS at https://lf.example.local/lfdssts/ and an external DMZ one at https://lfext.example.com/lfdssts/. In that case, you need to ensure both STS sites are registered correctly in LFDS with the respective internal/eternal STS SAML endpoint URLs. Still, the distinction to the IDP is not actually "internal" vs "external". The IDP simply needs to have a list of all the SP SAML endpoints where requests can come from and responses be sent to. They could just as easily be two different internal STS instances with different URLs (say Dev and Test).

To your second question on network security, as discussed above, LFDS does not communicate directly with the SAML IDP on any port.

If you are using a reverse proxy to provide external access to an internal STS instance on the same machine as LFDS, it is critical that you block external access to the LFDS web admin interface. Do this by either:

  1. Use layer 7 proxy path-based routing features to block all traffic to "/LFDS" and  "/LFDS/*" (return a hardcoded HTTP 401/404); or
  2. Use the IIS IP Address and Domain Restriction feature on the /LFDS IIS app, as I describe in this Answers response.
0 0
replied on October 10, 2022

Hello Sam,

We were able to get their IDP to connect with LFDS SAML setup.

We had to do a few  tweaks to the Claim Identity->Claim Type->Email address, were their IPD changed the format to domain\alias.

Once we updated this, we were able to use their Windows accounts to log into Forms and Web Client.

Appreciate the pointers,

Jeff

1 0

Replies

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

Sign in to reply to this post.

Details
Related Posts
Loading ...