Restrict login to "members of those groups" without memberof overlay

Hi,
I’m trying to choose a shared storage OSS app for our organization.
I’m unsure if seafile provide this feature ? Which by the way is very basic

Nexcloud/Owncloud isn’t. So I’ve filled the feature request to Nextcloud : https://github.com/nextcloud/server/issues/5620

Cheers

Hi,

why do you want to avoid using a memberOf-Filter?

Imho it’s not wise to implement this kind of special use cases without a good reason. I would prefer a general solution like a hook to an user defined function that is executed at the end of the log in process.

An immediate solution might be to switch over to federated authentication (shibboleth). Then you can add any restriction you want like this to your webserver configuration:

   <Directory "/shib-login/">
         AuthMerging And
        AuthType shibboleth
        ShibRequestSetting requireSession 1
        <RequireAll>
            # ---------------------------------------------
            # Manantory: a valid shibboleth session
            # ---------------------------------------------
            require shib-session
            # ---------------------------------------------
            # Check for attributes like group membership
            # ---------------------------------------------
            <RequireAny>
               # must be a member
               require shib-attr groups GROUP1
               # must not be a member
               require shib-attr groups ! GROUP2
           </RequireAny>
        </RequireAll>
    </Directory>

Best regards

Thomas

Hi,
That’s not “avoiding using a memberOf-Filter”, it’s simply that Openldap default config doesn’t ship with memberof overlay enabled. So there is no memberof operational attribute available from users entry in the directory. It’s still possible to enable it but then you have to reset all the LDAP groups to make the said attribute to appear.
All it would cost for seafile, nextcloud or owncloud software is to provide that feature would be to perform an additional search from the members of the specified group. Then it would be 100% compatible with regular, non-memberof LDAP setup.

Thanks for the shibboleth tip by the way !