SAML user provisioning

Seafile Server
#1

I am thinking about moving to SAML based SSO once Seafile 11 Pro is released.

One thing I couldn’t figure out from the documentation is whether Seafile supports auto-provisioning of users. If yes, which attributes are used to determine the matching? As far as I understood, Seafile 11 will have a separate matching table between the internal users and the SAML attributes.

How are existing users handled?

Thanks for your answer.

#2

@daniel.pan @Jonathan Any thought here?

#3

There is a table recording the map between external ID and internal ID.

CREATE TABLE `social_auth_usersocialauth` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `username` varchar(255) NOT NULL,
  `provider` varchar(32) NOT NULL,
  `uid` varchar(255) NOT NULL,
  `extra_data` longtext NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `social_auth_usersocialauth_provider_uid_uniq` (`provider`,`uid`),
  KEY `social_auth_usersocialauth_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  • The username store for the current ID used for the user in ccnet.EmailUser table.
  • The uid store the external ID used in your SAML.

To map SAML user to existing users, just create a map record in the table.

#4

Thank you daniel!

How is this map populated? Is there an automatic matching according to the email addresses?
Or do I have to manually fill this map?

What happens when a user tries to log in, that doesn’t have an account yet? Is the account automatically created? Is there a way to set default permissions/access to shares? Is it possible to map admin access to a SAML assertion?

#5

For existing users, you have to add mapping manually by modifying the database.

For new users, an account will be created automatically.

Is there a way to set default permissions/access to shares? Is it possible to map admin access to a SAML assertion?

There are no such features yet.

#6

Thank you for explaining this further.

Since the mappings need to be created manually, it would be good to include this in the manual.

Could you also provide a list of valid values for the provider column? I imagine this would be oauth, ldap or saml, but I would rather not have to figure this out myself.

Also, what is stored in extra_data? Since this is NOT NULL, it would be helpful to know what should be put in there.

Most importantly, I don’t understand why there is an attribute mapping section in the config file, if this does not allow to map the attributes in such a way that the email address provided by the IdP can be used to match a login to existing users. It seems that the only thing that is actually used is the uid.

#7

@daniel.pan ?

#8

‘Could you also provide a list of valid values for the provider column?’ —Allowed providers are: LDAP, OAuth, SAML, Shibboleth, CAS.

#9

Thank you @wangjianhui ! Where can I find the documentation for this? And do you by any chance know the answer to my other questions?

#10

‘Also, what is stored in extra_data ?’ ---- The extra_data field stores user information returned from the provider. For example, when integrating WeChat (a very common single sign-on method in China), some necessary information needs to be stored; for other providers, the extra_data field is usually an empty character.

1 Like
#11

You can refer to here: Outline - Seafile Admin Manual

#12

Thanks! I already found that documentation. However, it does not contain the answers to the questions I asked here, hence I created this thread.

The lack of proper documentation makes it really hard to plan something and create working config files in advance. In a production environment this is very frustrating when trying to not have downtime.

The documentation is not really a documentation but rather a guide on how to set it up. Which is fine, but it is not a documentation.
A documentation should in my opinion look something like this: Predefined variables reference | GitLab

#13

This is still a feature in progress. Thanks for the suggestion about the document. We will update the document soon.

#14

Thank you @daniel.pan .
Nowhere does it say that SAML integration is still in beta. This is quite disappointing, and I’m not sure we’re going to renew our license.

I understand that you are quite a small team and that not all features can be perfectly implemented. But at least put a note in the documentation that it is not yet finished. I also don’t see anything about this on the roadmap.

I feel like Seafile could really benefit from taking a step back, reworking the docker containers (like here: https://github.com/ggogel/seafile-containerized) and rewriting the whole documentation so that it is up to date, complete and consistent.
At this point I don’t even feel like using SAML or any other SSO is worth it with seafile, as any timesavings from that are eaten up by having to ask for every single detail on the forum.

#15

I mean that the ability to associate existing users with SAML integration is still in beta. We recently redesigned the user identity management mechanism in Seafile version 11.