testing group membership

[Bennett, Steve]

>> I'd like to limit access to a SP to users that are members of a 
>> specific group.

> Note that attribute policy is not how you configure authorization in the SP.

I'm not specifically aiming to handle authorization (even though it amounts to the same thing). I want to restrict which users' attributes I release: I don't want the SP to be able to have access to attributes of any users other than those that have been centrally approved to use the SP. 

> Are these forward referencing memberships actually stored in the subject's
> LDAP object or are these maintained by the memberof overlay?

They're actually maintained by the memberof overlay, but that's OK (I think).

> The SP doesn't know anything about LDAP or groups or hierarchies of objects.
> Values of string-typed attributes are just that, strings.
> If you want the SP itself to check for groups you'll have to flatten them, yes 
> This of course has the potential of producing many group memberships for a single
> subject and may not scale well. Unless your SP is a platform which manages and
> uses those groups itself in the application (probably via LDAP) most of those groups
> may not even be revant for the SP, so filtering them at the IdP might be in order
> (i.e., only send those group memberships to the SP which are relevant).

That's why I want to limit the release of a user's attributes by nested group membership, calculated at the IdP. That way, I don't have to care about the capabilities of an SP, and I know that the administrator of the SP only has access to information on the users that use the SP.

Steve.