Hi all,
I’m migrating authentication on our Seafile Pro server (Docker) from LDAP to SAML, with the goal of dropping LDAP entirely.
I’ve set up the IdP and enabled SAML. When I log in via SSO with a user that was previously imported through LDAP, everything appears to work correctly. I can see my own libraries. However, in the social_auth_usersocialauth table I’m seeing two rows for the same user: one with provider set to ldap and another set to saml. The username and uid values are identical.
Is this expected behaviour? Or did I miss a step somewhere? Should the ldap row be deleted or modified before the user logs in via SSO, or is it safe to leave it as is?
Any guidance would be much appreciated. Thanks in advance!
This is indeed the expected behavior in Seafile 11.0 and later versions.
The social_auth_usersocialauth table is used to map external identities (from LDAP, SAML, OAuth, etc.) to a single internal Seafile user account. When a user who previously logged in via LDAP now logs in via SAML, Seafile creates a new entry for the saml provider. As long as the Unique ID (UID) provided by your SAML IdP matches the attribute previously used for LDAP (typically controlled by the SSO_LDAP_USE_SAME_UID = True setting), Seafile correctly links both to the same account, which is why you can still see your libraries.
Regarding your questions:
- Is it safe to leave it as is? Yes, it is perfectly safe and expected. The presence of both rows confirms that the migration/linking process worked correctly.
- Should the LDAP row be deleted? It is not necessary to delete it. If you eventually disable LDAP entirely and all your users have successfully logged in via SAML (creating their
saml rows), the ldap rows will simply become dormant. You can choose to clean them up later for database “neatness,” but it won’t affect the functionality of SAML logins.
For more details on how Seafile handles authentication identities since version 11, you can refer to the Upgrade notes for 11.0.x.
1 Like