Shibboleth affiliation and multi-institution


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 “*” 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)

[edit] 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.

Thank you for your response,

For the first question, you can find information on how to define roles via Shibboleth affiliation attribute here: (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… :confused:

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. :confused:

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…

Thanks for the suggestion. We haven’t thought about it before.

What do you mean by “Joker”?

Thanks for trying. So my memory was wrong, managing libraries and groups of institution admin has not been added yet. We will add more features for institution admin in the future.


I mean special character use. For example some things like this : * 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).

Thank you

1 Like

Hi all,

I’m looking for a way to assign different roles (member, guest) from a specific shibboleth attribute.
I’m trying to configure these options

    "eppn": (False, "username"),
    "givenname": (False, "givenname"),
    "sn": (False, "surname"),
    "mail": (False, "contact_email"),
    "supannEtablissement": (False, "institution"), # this a specific attribute from French Supann Schema
    "eduPersonScopedAffiliation": (True, "affiliation"),

Then add new config to define affiliation role map,

    '': 'member', # OUR USERS 
    '*': 'guest'                           # ALL OTHER  USERS  

I suppose that joker * would match all others cases different from ‘’ (who would get member role)
All other affiliation would then take the role guest automatically.

Is that possible ?
Is there any variable that could be used to set default shibboleth role to guest (or any other role) ?



Hi @daniel.pan,
do you have any clue on wildcard use ? This would help us very much.

We don’t have such a feature yet. We will add it in the next maintenance release.

Great ! Thank you, @daniel.pan


Hi Daniel,
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:

‘employee@…’: ‘employee’,
‘faculty@…’: ‘employee’,
‘staff@…’: ‘employee’,
‘student@…’: ‘student’,

In this way unknown affiliations and accounts without this attribute automatically gets the restrictive default role assigned. No »catch all« assignment needed.

Best regards


Hi @scheff,

This is a good workaround, but i already have several users with roles already assigned.
I’d like to set the “by default” role without reassigning roles to registered users.


I’m quite sure that roles are assigned newly on every log-in. It’s sufficient to assign the desired affiliations.

Best regards


Thank you, i’ll try it. But :

  • i’m not really sure it’s a convenient way to reassign roles on every login;
  • i have many users that are non shibboleth users : the behaviour may be not the same in this case.




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.

Best regards


Hi @scheff,

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…



Hi gauburtin,

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’;

Best regards


Hi scheff,

We have different users (Shibboleth and Seafile).

For Shibboleth users, we can use the domain part of the mail address 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.




could you set showAttributeValues=“true” in your shibboleth configuration (file shibboleth2.xml) and post the output of


Best regards


Sure : 

Session Expiration (barring inactivity): 479 minute(s)
Client Address: 194.254.171.XX
SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Identity Provider:
Authentication Time: 2017-09-04T11:56:54.343Z
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Authentication Context Decl: (none)

givenName: prenom
primary-affiliation: staff
sn: NOM
supannEntiteAffectation: epcc;numerique
supannEntiteAffectationPrincipale: numerique
supannEtablissement: {UAI}0753742K
unscoped-affiliation: member;staff