Shibboleth Developers

["Michael A. Grady" <>]

>From the outside looking in:


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. 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).

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.

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.


> From: Parviz Dousti 
> <>
> To: 
> 
> Subject: Re: ARP editing scenario....
> I would like to go over each scenario and see if our current model will be 
> able to handle it.  It is obvious that we need two major functionality 
here:
> 
>       1- Some sort of authorization.
>               I think we have to bite the bullet and implement this 
ourself.  I would 
> post a proposal for this soon.
> 
>       2- Support for editing multiple ARPs in UI.  This should not be very 
> difficult to implement.
> 
> Assuming we have the above let's see how each scenario plays out.
>       
> 
> >
> > -- campus library licenses resource X. Site creates an arp that:
> >      - releases AFFILIATION=MEMBER
> >      - blocks release of EPPN
> >
> - Admin creates an ARP:Resource obj in Default/Admin ARP with resource 
> com:resourceX:www
> - Adds 2 ARP:ATTRs to this.
>         - One for EPPN with exclude = y.
>         - One for AFFILIATION.  Add a filter to this with value = "MEMBER" 
and 
> include = y.
> 
> > -- user wants to create an ARP. They enter the url for resource x. Edit
> > screen shows them that
> >
> >      - AFFILIATION = MEMBER is being released; they cannot change this
> >      - other attributes and values can be released
> >      - EPPN is blocked; it CANNOT be released
> >
> > they select to release AFFILIATION=STAFF
> >
> - User creates an ARP:Resource obj for com:resourceX:www.
> - Adds Attribute AFFILIATION.
> 
> * Notice that user does not need to and cannot set a specific value.  If 
> that value really exists for this user (i.e STAFF) it would be returned 
> when asked by a SHAR.  Actually user does not need to do anything for this 
> to happen since Admin already created and AFFILIATION ATTR for this 
> resource but it is harmless for user to do so.

This is different, in that the default policy you listed above, if I read
it correctly, explicitly only releases the MEMBER value. If the user
specifies to release AFFILIATION, doesn't that then release all values
that they have for AFFILIATION?

> 
> > -- user wants to create an ARP for http://www.resourceX.com/editors/.
> > They enter this url. It does NOT match any existing url, so they can
> > specify that any and all attributes can be released.
> >
> - User creates an ARP:Resource for com:resourceX:www:editors
> - Adds whatever ATTR s/he wants.
> 
> > -- user wants to create an ARP for http://www.resourceX.com/index.html.
> > The ARP editor figures out that this is the same as the url entered by
> > the site in scenario 1.
> >
> - UI checks for resource com:resourceX:www
> - Finds it and  works in "edit" mode.
> 
> > -- down below, there are SIX scenarios from a previous note. Numbers 1-5
> > all seem to raise authorization related issues.... eg who can specify
> > that "enrolledCourse=Chem101" can be released? anyone? is this a
> > directory issue?
> >
> > ------------------------- this is the list from a previous note.
> >
> > On monday's call, I agreed to try to develop scenario's describing some
> > of the more "likely" real-world situations we should expect to encounter
> > on campuses. Once we agree on a set of use cases, we can start to 
explore
> > the implications for the UI, and for the underlying campus middleware
> > infrastructure.
> >
> > 1- Jane Doe is teaching Chem 101. She has convinced a friend at another
> > university to grant the Chem 101 students access to a controlled web 
site
> > in the friend's department. Jane goes to the AA user interface,
> > authenticates, and then enters an ARP that specifies that
> >
> >      - for any student in Chem 101
> >      - accessing the target "friends web site"
> >      - the attribute "enrolledCourse=Chem101" will be released.
> >      - she also enters a filter blocking the release of EPPN (in case 
any
> >      individual student attempts to create their own ARP releasing EPPN)
> >
> > Q's - how do we know Jane is authorized to do this?
> >      - if a student creates their own ARP, attempting to override 
Jane's,
> >      would we, could we find Jane's filter? Or does the site admin have 
to
> >      enter that?
> >
> 
> - Admin creates a new ARP:Resource for ALL users in Chem101
> - Sets the ACL for ALL of them so Jane can create ATTR under this 
resource.
> - Jane runs the UI and adds "enrolledCourse" ARP:ATTR for ALL users in 
> Chem101.
> 
> * note that blocking EPPN may not be necessary here. Say "friends web 
site" 
> is not in Default ARP.   When AA_Responder goes over Default ARP "tree" it 
> matches a more general policy (e.g. EDU:) and blocks EPPN.
> 
> Alternatively,  Admin can create a "friends web site" ARP:Resource in 
> Default ARP and add "enrolledCourse" and EPPN  ARP:ATTR.  That would be 
> enough.  Everybody who visits the site would send their "enrolledCourses". 
> If the value Chem101 is there, they get in.
> 
> > 2- Chem 101 again. Except the grad student TA enters the ARP. How do we
> > know this person is authorized?
> >
> 
> - Same as #1
> 
> > 3- Several faculty and grad students in the planetary geology group at
> > State U are members of a multi-campus research project. One of the grad
> > students manages ARPs for the group. A new controlled web site is 
created
> > at Other U. The ARP manager enters a new ARP specifying:
> >
> >      - for any member of the planetary group
> >      - accessing the site at Other U
> >      - the attribute Extension
> >      URI="urn:mace:state.edu:group:geology:planetary-group" will be 
released
> >
> > Q's - any authorization issues?
> >      - presumably, we want the ARP manager to see a more user friendly 
UI
> >      than having to enter this URN... what should that look like?
> >
> - Again this is similar to #1.  Don't know much about the URN thing.
> 
> > 4- Joe, the office administrator in the Office of Faculty Governance, is
> > also the webmaster for the office. He wants to give all the faculty
> > access to a new web site containing the reports of a Task Force. He
> > enters a new ARP specifying:
> >
> >      - for any member of the faculty
> >      - accessing this new web site
> >      - release the attribute "AFFILIATION=FACULTY"
> >
> 
> - In general nothing.  The fact that we have a general policy for 
releasing 
> AFFILIATION would take care of this.
> 
> > 5- Jane Doe, the Department Manager in Physics, is also responsible for
> > managing the ARPs controlling access to resources licensed by the
> > department. The department licenses access to BLAH, a journal devoted to
> > articles about the new sub-atomic BLAH particle. She enters an ARP
> > specifying:
> >
> >      - for any member of the physics faculty
> >      - for an grad student in Physics
> >      - any undergraduate Physics concentrator
> >      - accessing the BLAH journal site
> >      - release the attribute Entitlement 
URI="urn:mace:blah.org:contract1234"
> >
> > Q's - any authz over who can specify the release of this URI?
> >      - a friendly UI.....
> >
> 
> - I guess I have missed all discutions on Entitlement.  If this is an 
> Attribute,  then the given URI  needs to be set for all physics 
> associates.  I am not sure I understand this though.
> 
> > 6- semester roll-over. The site admin does something to remove all of 
the
> > ARPs from the AA that are related to courses taught last semester.....
> > and then loads the "standard set" of course-related ARPs for the 
upcoming
> > semester.
> >
> 
> I think the clean up needs to happen based on Resource.  Either on Default 
> ARP or ALL users.
> >
> 
> 
> 
> 
> 

--
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--