Then it says could not find specified attribute http://schemas.xmlsoap.org/ws/2005/05/idenity/claims/nameidentifier
Why is xmlsoap.org governing users login to laserfiche.com?
That is the uri for the identity in SAML, see https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims. It obviously looks like it could be a url, but that is irrelevant to the login process.
That said, I don't have an answer about why logging in is failing, other than the SAML response doesn't contain the required information. This could indicate a problem on our end, or something was lost in transit. Is this a recent error? Is it working now?
The customer was getting it as of Friday in their trial cloud system. They are trying to test out going to cloud but can not even login. An error like this has me at a loss, I have no idea where to start with troubleshooting.
The only thing I can think of that is called an attribute, is the mapping of LDAP attributes when configuring ADFS. However attributes have text names, not website names like this. There is no attribute titled http://schemas.xmlsoap.org/ws/2005/05/idenity/claims/nameidentifier
Update: There is also nothing called SAML Name
Here's a working config from the Laserfiche Cloud side on one of my test systems:
Note that I've set the "Customized user identifying attribute" to the UPN attribute of "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn". I believe that's how AD FS labels the outgoing "UPN" claim in its tokens by default. Since it looks like you're already sending UPN on the AD FS side, try setting it as the identifying attribute on the Laserfiche Cloud side like I have above.
As Brian noted, the "https://schemas.xmlsoap.org/*" values are URIs that come from standards documents defining SAML claim attribute formats and have nothing to do with that website as part of the actual auth flow. See: https://www.ibm.com/docs/en/security-verify?topic=source-saml-assertion-verify-credential-token-mapping
Hi Samuel
The customer's IT actually did it the other way around this afternoon, they set the claim for User-Principal-Name to NameID instead of UPN. Is this OK? It allowed their users to login to the system after they did this.
We didn't even know about the Customized user identifying attribute field until just recently from another answers post. I understand that it defaults to NameID which is why the system was upset that nothing was mapped to /nameidentifier on the xmlsoap.org page?
Yeah, that's fine. What they did is functionally equivalent to what I recommended.
We did try it the way you recommended just now as well and it also works.
Unfortunatly support said we should not be doing this, they want the User Identity Attribute in LF Cloud to be set to NameID and the User-Principal-Name within the ADFS claim issuance policy to be UPN.
However when we mis-match them like this, no one can login. It is really frustrating since we thought we had it figured out.
Send the UPN claim twice from AD FS. Once with the built-in outgoing claim type UPN, once with outgoing claim type "http://schemas.xmlsoap.org/ws/2005/05/idenity/claims/nameidentifier".
That way you're both sending the UPN as the NameID as the primary key for account matching purposes, as well as UPN as UPN for anything in LF Cloud that's trying to look for the specific UPN value (since the NameID attribute technically supports a variety of different formats, while a UPN attribute should always be the UPN).
No luck with that, just tried it. Since Laserfiche uses NameID as the User Idenitifying Attribute, the only thing that works for us is to have a claim for User-Principal-Name as NameID OR to modify with a custom attribute as you described above.
We are using the custom attribute you recommended now and hope that support will approve this, since it allows us to set User-Prinicpal-Name to UPN as they are requiring.
I am confused why the default for User Idenitfying Attribute would ever be NameID. This doesn't appear right. The default should be UPN.
Not all SAML SSO providers are backed by AD as an identity provider, and UPN is an AD-specific attribute.
Well then it seems for AD customer's, using the custom value you provided above is the way to go.
Althought support said it will work with AD using NameID in LF and UPN in AD, I just can't get specifics on how they got that working or why it matters that it is setup that way.