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

Discussion

Discussion

Cloud - Assigning Security Rights with Azure AD seems super confusing

Laserfiche Cloud
Updated July 22, 2022
posted on July 20, 2022 • Show version history

With Azure AD the groups are called Federated Groups, but you can't assign a Federated Group access rights any longer, like you could with Active Directory Security Groups.

We can assign a Federated Group to a Laserfiche Group, then assign access rights to the Laserfiche Group.

However if we go to look at who is in which Laserfiche Group, there is no informaiton like that, it doesn't actually show them as a member of the group (even though they are treated as one).

We can go in Azure and look at which Fed Group they belong, but then when we go assign security it must be by Laserfiche Group. 

We have to go look at which Fed Group is assigned which Laserfiche Group.

The whole thing seems much more disjointed over Active Directory.

0 0
replied on July 22, 2022

This is exactly the same as SAML groups in self-hosted LFDS in non-Linked Provider scenarios. You add SAML groups to Laserfiche (LFDS) groups, and set security within the application on Laserfiche groups.

Users' SAML claims contain a Groups attribute with a list of their SAML group names. The origin of these group names is irrelevant. 

I have found it helpful to remember that a "SAML/Federated Group" registration in LFDS/ACS isn't much more than a group name string that LFDS/ACS match against entries in a SAML token groups claim. That is why at a technical level the group format is basically irrelevant as long as you get the group name strings in the SAML token and the SAML/Federated Group registration to match. They could be auto-generated 64 character random strings, Group SIDs, AAD Object IDs, hashes of any of the former, etc., as long as they line up on both sides.

For the sake of administrators' sanity, we recommend using the human-readable group names.

LFDS/ACS and other LF applications have no way of looking up and displaying SAML/Federated group membership because they're not security groups in the way AD security groups or Laserfiche groups are. Instead, they're entries in an LFDS/ACS mapping table that evaluates users' group claims at login time and determines what Laserfiche group membership should get added to their LFDS/ACS token for that session.

This is not some Laserfiche-specific problem. SAML is purely an authentication protocol and doesn't have any mechanisms for group lookups and a ton of other identity management functionality we've come to take for granted with Active Directory Domain Services. The System for Cross-domain Identity Management (SCIM) standard is intended to cover some of this feature gap around user provisioning in cloud solutions and provides functionality conceptually similar to AD Group Sync in LFDS. Laserfiche Cloud now supports the SCIM version Azure AD uses. 

For administrative simplicity, I and others have found it helpful to have 1:1 matching between Federated/SAML groups and Laserfiche groups and use exactly the same names for both. E.g.,:

  • Federated Group: "Laserfiche Prod Forms Designers"
  • Laserfiche Group: "Laserfiche Prod Forms Designers"
    • Only member: Federated Group "Laserfiche Prod Forms Designers"

 

Etc. If you adhere to that where feasible it eliminates most of the sorting out nested group membership because it's always 1:1 and the names are the same regardless of where you're looking.

Hope that helps. SAML is really its own beast, and a rather complex one. My biggest takeaway from years of working with SAML is that if you try thinking about it in the same way as on-prem AD you're going to end up frustrated and confused over and over again. The more you understand how it works at a base level (every claim/attribute is part of a matching game where everything has to line up), the less you'll get stuck on the various pointy bits during configuration.

1 0
replied on July 22, 2022

Got it, I was thinking that would be a better approach. If the group names in Laserfiche were the same group names you see in AD, then you would tell who was in which group just like in the classic domain controller days.

 

It just wans't clear that it wasn't going to be clear, so they had different groups names in LF than the Fed Group names.

 

This is really the first we have had so much feedback regarding domain services being difficult to "hook up". Specifically with IT departments connecting cloud to AD FS, Okta, and now Azure AD.

 

The SAML protocol might be bringing new features to the table, but lots of features without intuitive user interface design usually leads to frustrated end users.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...