testing group membership

[Peter Schober]

* Bennett, Steve <s.bennett at lancaster.ac.uk> [2013-04-17 11:04]:
> 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. This is about what attributes to accept (so you could filter
out e.g. a specific entitlement from all but a specific IdP or some
such. The default is to prevent an IdP issuing scopes registered for
another IdP).

For authorization see
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPProtectContent
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAccessControl

> This works for some cases: if the user is a direct member of the
> group, they have an isMemberOf attribute that matches the value, the
> policy matches and they get access to the SP.  However, we have
> nested group memberships, e.g. "userA" is a member of "groupB",
> which is a member of "myGroup", so userA doesn't actually have an
> isMemberOf attribute that matches myGroup.

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

> So... is there a straightforward way of doing nested group
> authorization in Shibboleth? Our group memberships are in an
> openLDAP directory at the moment. One approach that I can see would
> be to maintain a "flattened" representation of group membership
> (perhaps in a database rather than bloating the directory), but it
> would be nice if there was a more elegant solution.

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 (either in the directory or maybe within the IdP).
This of course has the potential of producing many group memberships
for a single subject (dozens, hundrets, maybe thousands) 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).

There might also be ways to do that via OpenLDAP's overlays, but I'm
not aware of an existing one that does that. You'd need to ask on the
openldap list.

mod_authnz_ldap would help here, the AuthLDAPSubGroup* directives
are available in httpd 2.4 for exactly that, but that's in 2.4 only.
  So provided upgrading httpd is an option and the SP in question has
access to your DSAs you could then use mod_shib for authenticaton/SSO
and mod_authnz_ldap for authorization.
-peter