Shibboleth Developers

["Diego R. Lopez" <>]

Hi,

Reading what Thomas is asking for and what Tom and Scott says, I'd like
to say a couple of things:

First, I agree with Thomas in that this kind of scenario is going to be
a must in the very moment users realize of the potential of
attribute-based authorization (we have already experienced these
requests), and with Scott in that a virtual organization has to be
undistiguishable from a "real" one inside the middleware space.

Second, following what Scott expresses about explicitly including this
kind of functionality inside Shib itself, I'd say that this is not the
approach to follow. As far as I can see, Shibboleth has to do with the
exchange of atributes between trusted sites and its work should not be
complicated by making either side (target or origin) dealing with 
subtleties like group membership and how to express it.

This is the point where authorization engines come into play. The target
site in the example of Thomas can take the received attributes and pass
it to the authorization engine, which in turn will contain the rules
for connecting to the appropriate "group directories" (whatever they
are) and verify whether the group membership holds or not. This sort
of things can be done, for example, using the LDAP boundaries
implemented by SPOCP. In this way:

1) The identity management infrastructure concentrates on moving and
   verifying identity attributes sources and policies.

2) Group management is circumscribed to its "natural" location inside 
   directories and metadirectories

3) Group-awareness is also kept in an external element that deals with
   all other the authorization details (like time constraints, for
   example), keeping the infrastructure simpler to manage and scale.

Be goode, 
-- 
"Esta vez no fallaremos, Doctor Infierno"
 
Diego R. Lopez

 
RedIRIS
The Spanish NREN
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------