Shibboleth Developers

["Michael A. Grady" <>]

You're right. I guess my real concern is that whatever 'field' 
is set aside for 'uids' accommodates a longish value -- think a
dn for a group, or even an ldap filter. I presume that you are
building a web interface for maintaining the ARPs. If you
build this with an 'authorization routine' that is called with
the contents of the uid field and the action being requested/attempted,
then it will be easy to change that routine to interpret the 'uid'
as an ldap filter, and go from there as far as returning a yes/no
'authorized' answer. And, just for allowing a broad interpretation
of what is appropriate in the 'uid' field, I think that field should
be given a name (and documented) that is fairly broad/generic --
e.g. allowed_agent_identifier, owner_identifier -- something that makes
sense to be a given a broad interpretation as to its contents. I suppose
there could also be an associated flag that indicates how to interpret
this field -- as a uid (or set of uids -- not sure if you are planning
a separate table for these to accommodate multiple values or a syntax
for a list), as a dn, as an ldap filter, etc. But I don't have strong
feelings on that.

Then the delivered core code can have the 'check_authorization' routine
just assume it is being given a set of uids, action, and the id of
the user logged in, and that will be the one routine we need to
change to instead hook in an ldap directory for this.

Scott Cantor wrote:
> 
> > My personal opinion is that building anything that encourages
> > yet another silo of hard-coded usernames is the antithesis of
> > the thrust of the Internet2 Middleware effort. And I'm going
> > to disagree with Scott here -- building this in is worse than
> > building in nothing.
> 
> We have to be careful in the design. As a matter of initial
> implementation, I don't think what we're talking about is a problem, but
> I very much agree that the design should accommodate pluggable "decision
> resolution", if you will, so that authorization can rely on external
> infrastructure if it exists.
> 
> If we're designing with objects, those objects should be able to tell
> the AA who is authorized to use them. How they figure that out can be
> overridden. If that's more or less what you were aiming at, we're not in
> disagreement on that point.
> 
> -- Scott

--
Michael A. Grady                             

Senior Research Programmer                   http://ljordal.cso.uiuc.edu
Computing & Communications Services Office   (217) 244-1253  phone
University of Illinois at Urbana-Champaign   (217) 265-5635  fax
Rm. 103, MC 680, 2212 Fox Drive, Suite C     Champaign, IL 61820

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--