surfnet-niels
commented
9 years ago Hi,
A few thoughts:
- I have always been a bit confused in regard to using hasMember in 'attribute land' (it works fine in LDAP land though), as I think hasMember is declared as an attribute of a group, not of a person:
| The hasMember attribute associated with a group is a collection | of values each of which identifies an entity that belongs to the | group. attributetype ( 1.3.6.1.4.1.5923.1.5.1.2 NAME 'hasMember' DESC 'identifiers for entities that are members of the group' EQUALITY caseExactMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
So a person cannot have members, only groups have members. Not a problem you might think, but I then wonder, so how could I ever get a SAML hasMember attribute for a group? An authentication deals with people, so hasMember has no context there. The same goes for AA queries. So how do I query an AA to give me a hasMember Attribute?
- An implementation issue here is that this might be a very long list, as one could e.g. request "students@university". The VOOT REST API has protection against this as it supports start and end and a way to signal you got result 1 to 10 out of 100.000. No such thing in SAML though, so you can only send everything :(
- And then finally a big privacy issue: As also already noted on the use of the identifiers: The only technically sensible thing to do here is use ePPN like identifiers. That is the only thing that works across multiple SPs. But: by sending an SP many such ePPNs as part of a statement is a direct violation of minimum disclosure. Whereas a normal SAML AA query at least requires the SP to be knowledgeable about the ePPN of a user (and thus a relation between SP and IdP must be in place in some way), this is just basically a fishing option and should only be allowed if there is a very good trust relation between AA, IdP and SP. Group membership is a privacy sensitive attribute, just like the others.
biancini
Hi Niels, regarding attributes and their semantic, friends from Renater and from Cesnet were suggesting to manage another attribute (in addition to isMemberOf). This attribute would be "hasMembers" and must provide a multivalued field containing all members of the groups the user is member of. This field would include information that could be also retrieved from VOOT, but will help some application to have the relevant information about co-members of the logged in user (which seems to be enough to some use cases).
So for every group listed in isMemberOf, this field should have a value with the following structure:
Where localGroupName is the same name contained in the IsMemberOf and member is a list of members' unique identifier (including the user himself).
An example of the values contained in this field could be: group@grouper.garr.it: biancini@garr.it farina@garr.it
What's your opinion on this? Cheers, A.