group memberships from two sources

[Cantor, Scott]

On 3/5/13 3:18 PM, "David Bantz" <dabantz at alaska.edu> wrote:

>(1) Our first request for group membership requests the group membership
>from these two sources be passed in different SAML attributes (there is
>little overlap in the group membership data in the two sources).  This
>seems reasonable enough to me, but am
> I missing some problem that this would entail?  I guess this has two
>parts: 
>Is it appropriate to resolve and release the bare directory attributes
>(as opposed to tidying them up in some way as suggested in
>https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttribu
>teDefinitionExamples)?

What tidying is it suggesting?

>Is it appropriate to keep these in separate attributes for release
>(rather than combining them)?

It seems like a questionable idea to me, but YMMV.

>Do I simply have two resolver definitions like:

You have them both mapped to the same SAML 2 attribute there. FriendlyName
is a meaningless field, but you seem to be relying on it to disambiguate
the two. Also, neither of the SAML 1 names exists. You can't create
attribute-def URNs like that, and we don't use them any more for any
attributes defined since the original set.

Assuming that's the OID defined for isMemberOf, that would be the same
attribute name for both SAML 1 and SAML 2, but that's only one name, you'd
have to invent your own for the second. If you wanted to use the OID
Microsoft defines for their attribute, that would be one way to do it.

All in all, it seems like a bad idea vs. just using isMemberOf or whatever
is in eduPerson. For SAML purposes, why perpetuate all the weird history
of group membership attributes vs. just picking one that exists and going
with it?

-- Scott