Seafile 11 Migration: LDAP and SSO

New problem :slight_smile:

Starting point: The authentication system for Seafile is LDAP (email/password), which is also used for managing user and groups, etc. We also have an internal SSO service to avoid re-entering credentials (email/password) (Note: using email as a login is not common in our internal process). Everything works fine in version < 11 users can authenticate via LDAP and/or SSO.

After upgrading to version > 11, I ran into several configuration issues:

Following the upgrade notes: Upgrade Notes for 11.0.x mentions migrate_ldapusers.py …
done. It’s possible to log in using SSO and LDAP (login and email) … works fine.

But the system continues to evolve, and new users are added to LDAP. Now the issue is, it creates two virtual IDs for the same user in SSO and LDAP.

What did I miss?
Thank you

The correct way is let the user first login via LDAP. Then in the user’s profile page, the user can link the current account to SSO account.

Otherwise, you as system admin need to manually create entry in social_auth_usersocialauth to map the SSO uid to the same internal Seafile user ID.

Hello,

The method of linking accounts via the user profile doesn’t seem feasible to me:

  • Technically, I don’t see any option to link the LDAP account to the SSO account. There’s nothing available, whether for LDAP or SSO (same email).
  • From an IT support perspective, it’s impossible to apply this procedure to all our users. It’s way too tedious to document, and it would result in a flood of support requests due to user confusion.

The second method, where no user action is needed, seems more doable at our scale… but I’m still not convinced!

If I understand correctly, the user still needs to log in via LDAP the first time. Their group memberships are only linked to the virtual ID from the LDAP provider. I could reduce the LDAP sync interval to 4 minutes with the option (LDAP_SYNC_INTERVAL = 4) in seahub_settings.py.

I’m running this SQL query ( ~10minutes):

UPDATE social_auth_usersocialauth sso
JOIN social_auth_usersocialauth ldap
    ON sso.uid = ldap.uid
SET sso.username = ldap.username
WHERE sso.provider = 'lab-xxxx.fr'
AND ldap.provider = 'ldap';

it’s ok ?
I run this script every 10 minutes, but I can’t predict when a user will use either login method for Seafile.

There aren’t many new users, but Seafile is used inconsistently (some inactive users). The number of licenses might block Seafile usage if there are too many duplicate accounts and licenses.

I find the new authentication process problematic. Is there another method, or maybe I didn’t fully understand? Any ideas? For example, is it possible to have an option where if the UID already exists, it doesn’t create a new virtual ID, and the link is made automatically?

Thanks for your responses.

You need a script that check all LDAP entries in social_auth_usersocialauth and add a new entry with provider as ‘lab-xxxx.fr’ if not exists.

Your suggestion is inspiring. Maybe we can add an option to check existing LDAP entries before creating a new account when a user login via SSO. What SSO protocol do you use, SAML or OAuth?

indeed … :sweat_smile:

#sql
INSERT INTO social_auth_usersocialauth (username, provider, uid, extra_data)
SELECT ldap.username, 'sso.fr' ,ldap.uid, ldap.extra_data
FROM social_auth_usersocialauth ldap
LEFT JOIN social_auth_usersocialauth sso
    ON ldap.uid = sso.uid AND sso.provider = 'sso.fr'
WHERE ldap.provider = 'ldap'
AND sso.uid IS NULL;

OAuth

Hi, do you think the option could be added in a minor release of version 11?
I’m hesitant to upgrade to version 11 (pro) right now, as I might end up with a lot of user tickets to handle. Or will it only be available in the next major release, or not at all?

We will add this feature in a minor release of version 11 in the middle of October.

it’s great! thank you

Hello,

We have the same or a similar problem.
We are using Seafile Pro Server version 11.0.5 and are using OAuth with the configuration below.

When we update and a user logs in, a new entry is created under the users. Will this also solve the problem in mid-October?

ENABLE_OAUTH = True
OAUTH_ENABLE_INSECURE_TRANSPORT = False

OAUTH_CLIENT_ID = "XXX"
OAUTH_CLIENT_SECRET = "XXX"
OAUTH_REDIRECT_URL = 'XXX'


OAUTH_PROVIDER_DOMAIN = 'login.microsoftonline.com'
OAUTH_AUTHORIZATION_URL = 'https://login.microsoftonline.com/XXX/oauth2/authorize'
OAUTH_TOKEN_URL = 'https://login.microsoftonline.com/XXX/oauth2/token'
OAUTH_USER_INFO_URL = 'https://graph.microsoft.com/oidc/userinfo'
OAUTH_SCOPE = [ "User.Read", "profile", "email", "openid" ]

OAUTH_ATTRIBUTE_MAP = {
    "email": (True, "uid"),
    "name": (False, "name")
}

Best regards!
Matthias