There really needs to be a way to migrate from LFDS to SAML authentication, and overall better integration of SAML users into Laserfiche access control. Adding SAML authentication to an existing environment is currently a major headache, but it shouldn't be. Other systems have gotten it right, and the trick is to decouple the user object from the method used to authenticate them.
Laserfiche Rio currently maintains separate user lists for LFDS, AD, LDAP, and SAML users, and there is no integration between them. This creates significant and unnecessary complication when changing authentication methods or assigning and auditing permissions. It also makes it very difficult to migrate from one authentication type to another, since every user has to be recreated in the new database, while avoiding the creation of conflicting usernames. After this, all permissions, rights and privileges must be manually replicated from the original user object to the new one. Finally at the end of this, you are have an entirely new user, which means your audit history, object ownership, document checkout status, and any other user-related history are invalidated.
Consider that, currently, Laserfiche also provides no way to report on effective access or group membership when permissions are assigned to SAML groups because SAML group membership is assigned dynamically during logon and removed after logoff.
These issues can be avoided.
The way to do it is to first consolidate to a single user database but allow each user object to be enabled for one or more authentication methods. For each authentication method, the user object should contain a mapping to corresponding authentication data. Effectively, "linking" a Directory user to a corresponding AD, SAML, or LFDS user.
For example, a user with the LFDS username "Simon" might be enabled for AD and LFDS authentication. Simon's account would contain an Active Directory mapping that includes his AD username MYDOMAIN\simon and whatever other AD-related data is necessary to allow him to log in with his AD credentials. His user object would also have an LFDS mapping with his LFDS username and password hash and other LFDS-specific data.
Meanwhile, username "Betty" might be enabled just for SAML, and so her user object would have only a mapping for her SAML username, bettywhite@domain.com. She would also have an LFDS username, of course, but isn't configured to authenticate with that username.
Additionally, SAML group claims that are sent as part of a SAML login should assign the user to universal directory groups, not isolated SAML-only groups that essentially disappear on logoff. SAML user objects should retain their group memberships until and unless the SAML identity provider sends a new mapping during a subsequent login.
Structuring identity management in this way would allow authentication methods for any user to be added, modified or deleted at any time without affecting the user's ability to authenticate with the remaining methods and without changing the user's file access permissions or system rights. Developers could even integrate new authentication methods in the future that admins could enable with minimal impact.
Since permissions, rights, and privileges would be tied directly to users and groups, regardless of authentication methods, permission and access reports would be simpler and more accurate.