I’ve several questions/requests about Shibboleth roles affiliation configuration and about multi-institution support…
First for roles affiliation, is it possible to choose which role is assign by default for à shibboleth user, a local user, a guest ? or the only thing possible is to create a ‘default’ role which is automatically assign to authenticate user (local, ldap, shibboleth) and a ‘guest’ role which is automatically assign to user who are invited by some other user. If it’s not, is it planned ?
Is it possible to use joker in affiliation configuration something like “*@domain.com” or “*@domain.*” ? to use, for example, eppn to filter user to different roles ? If it’s not, is it planned ?
Have you some configuration example for affiliation ? (more than the current documentation in manual)
 About multi-institution, if I use a shibboleth attribute : ABC to filter/define differents institutions (sort of ‘branch’ of my company) but I also want other institutions which don’t define the ABC shibboleth attribute can connect to my Seafile too, is there a default institution that can be define ? or a way to configure multiple institution attribute ? or something like that… If it’s not, is it planned ? What about guest account ?
An institution administrator doesn’t seem to have many rights, he can only do thing at the user level (desactivate or delete) ? It would be great to chosse or increase institution admin rights, and to be able to name institution admin that are not a part of these particular institution.
It would be great to have little more documentation about all of that.
For the first question, you can find information on how to define roles via Shibboleth affiliation attribute here: https://manual.seafile.com/deploy/shibboleth_config.html (Search Affiliation and user role). This is a recent added document when the feature was added in version 6.0.7. So you probably missed it.
For multi-institution feature, a user does not belong to any institution can connect to Seafile too, just as the case the feature is not used. The institution attribute is an add-on, not mandatory.
A user can’t belong to multi-institutions. Guest account belong to no institution.
An institution admin can only admin the users in that institution. He can also manage libraries of the users belong to the that institution. The global system admin can admin all users. I think the institution admin don’t need to be in that institution, can you give it a try?
I see this documentation and I use it to configure my Shibboleth affiliation, I upgrade Seafile to 6.0.7 to use it, but it doesn’t answer my questions…
I think I find my answer, it seems that if we don’t define default and guest roles in server configuration file, default and guest roles exists and have permission as define in documentation… this point was not clear for me at first look (I think it necessary to define it in configuration file).
I think it would be great to have an option like : GUEST_ROLE = “name_of_role_i_chose_for_guest” and DEFAULT_ROLE = “name_of_role_i_choose_for_default_user”. This will allow to have default and guest role with different name that can match better for every Seafile configuration (more friendly name to use it in web interface).
And I think it’s not really a good idea to force a default configuration without any appearance in our configuration file because if we use it, and if one day you change or modify default configuration, if we don’t know or notice that, our configuration change without we realized it.
Joker for shibboleth affiliation would be a very great feature as multi-attributes affiliation.
Ok. What I was able to see by making some tests is that an institution admin can only desactivate or activate a user, and delete a user on his institution.
To be more specific when I click on “Administration” with a institution admin I only see a “User” tab, that’s it. If I click on a user I can see his Libraries but can’t delete/transfer it or anything else. Same thing for groups. When I fly over “Actions” column, nothing appear…
I mean special character use. For example some things like this : *@domain.com or *@domain* to have filter more smarter and “customizable”.
Ok, I think it would be an interesting feature. For me institution admin may have the (almost) same permission as system admin but only for there institution users.
Maybe the approach can be different and a system admin would have an administration panel with one more tab : users, institution admins, admin. In this tab he would have a list of user and match institutionS where they are institution admin, it would be great to be able to nominate user as institution admin for an other institution than there own. And it would be great too to be able to nominate user as institution admin for users who aren’t in an institution (like guest or local account = maybe use roles to “sort” them).
I tested the feature on 6.1.8 Pro. It works great ! Thank you.
I wonder how to define the “by default” role in case a non-shibboleth user creates an account when ACTIVATE_AFTER_REGISTRATION = True.
The “by default” role is set to “Default” (which is equivalent to “member”)
I’d like to set it to “guest”.
Is there any way to do so ?
I’m not sure, but in my opinion there already is a solution: Just define the default role as the most restrictive role (i.e. usually guest) and map all known affiliations (or other attributes) to other roles:
assigning roles dynamically based on the affiliation send by a trusted identity provider is the only secure way to handle status changes. It’s mandatory that Seafile accepts modified attributes (like affiliations, but also mail address, surname and given name).
I’m not sure if it is already implemented, but all other authentication methods should handle it in exactly the same way: It’s not mandatory to assign attributes, but if you do, it’s mandatory to accept them.
Your arguments are accurate, the roles assignaiton method needs to be solid and based on attribute in case of a large shibboleth population. But in some case (as ours), we don’t control attributes values nor users roles from our partners. Then, we sometimes need to keep the role consistent apart of the attributes values, except for the first login that should give the mimial role.
But this is a specific management. Your logic is the good one and we will tend to it when we will control the attributes values or at least, know the logic that give values to attributes…
to be courious: How do you decide which role should be assigned to a user, when not using attributes? The domain part of the mail address?
It would be a useful feature, if the Seafile would mark manually assigned roles and prevent overwriting this assignment during login, by inserting a new field »manually_assigned« (boolean DEFAULT false) into the UserRole table.
When it is really necessary to maintain the role assignment manually, I would do it in the database directly:
UPDATE `ccnet-db`.`UserRole` SET `role`=‘NEW_ROLE’ WHERE `role`=‘OLD_ROLE’;
For Shibboleth users, we can use the domain part of the mail address @campus-condorcet.fr fior members, all others () for guests, but it some cas we may need to manuelly assign member role to some of the () domains.
For local Seafile users, we do not use self registrattion for the moment (mostly because they are members by default…). We create users manuelly and assign them the guest role. But we could open registration if the default role is set to guest.
Your workaround could do the job. I don’t like to manually update the database (SQL) because of the constraints, but it seems quite secure for the moment.