Shibboleth Developers

["Michael A. Grady" <>]

I still think that descending into an authorization model for managing
ARPs will go too far, as there is no way to generalize it to cover all
situations and/or all models at all institutions. 

I think planning for the concept of an 'owner' attribute, or something 
similar, as is discussed in the Groups best practices document, is certainly
worthwhile, as a general mechanism to allow to identify who can modify a
given ARP. And talking about the hierarchy of what ARP specifications
take precedence over others, from some guidelines like (higher to lower):

 - my personal ones
 - 'intermediate agent' managed ones
 - 'centrally managed' ones  
 
Where the intermediate agent ones might need some sort of priority code
to indicate their precedence among each other, if more than one applies.
 
> From: "Scott Cantor" 
> <>
> To: "'Michael A. Grady'" 
> <>,
>  
<>
> Subject: RE: ARP editing scenario....
> Date: Fri, 29 Mar 2002 12:01:57 -0500
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> Importance: Normal
> X-Listprocessor-Version: 8.2.09/990901/11:28 -- ListProc(tm) by CREN
> 
> > >From the outside looking in:
> 
> Please, the more input the better.
> 
> > I sure hope that no one here is actually thinking of 
> > requiring institutions participating to go anywhere near this 
> > level of distributed management of ARPs anytime soon.
> 
> Requiring, no. The question is what we need to think about as it's being
> designed.
> 
> > You are 
> > getting far too far into the whole issue of attempting to 
> > manage roles and detailed authorization models within an 
> > institution, and away from the federated model that leaves 
> > much up to the local institution (within broad policy guidelines).
> 
> That's true, except if we don't at least come up with some assumptions,
> the code as delivered won't be able to do any of these things. That may
> be ok, I don't know.
>  
> > There is no way in any near-term deployment of Shibboleth 
> > that we (UIUC) would get into attempting to manage down to the
> > course/term level who is authorized to enter an ARP for a class.
> > We have a hard enough time figuring out a good way to keep track of
> > 'authorized agents' for an entire department or college.
> 
> So do we, but it's needed for all kinds of things. We're posting final
> grades to the student database, and the means by which professors are
> authorized to do this is very crucial.
> 
> > If you are considering these 'stories' just for deciding what 
> > kind of 'scaffolding' to build into the ARP model, that's one 
> > thing. But I can sure say that for a place like us, there 
> > will be default policies managed by us centrally, and then 
> > individuals can set their own, but there will be no 
> > 'intermediate agents' involved for a good while.
> 
> Most of it is definitely so that the design can be worked out in a
> forward thinking way, but for my money, our central IT organization will
> want to have nothing to do with this. I can already see their faces.
> They will want to farm it out and wash their hands of it.
> 
> So it depends on what your organization looks like and what they
> perceive their job to be (or in a better world what somebody tells them
> it is, but anyway...)
> 
> -- 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--