Shibboleth Developers

["Scott Cantor" <>]

This is long, but hopefully useful...

A general comment that it's implicit in all these scenarios that when
creating an ARP for a resource (based on URL), a matching step happens
to locate the correct ARP:SHAR container. If no match can be found, a
new ARP:SHAR with the hostname based on the URL would be created. Does
that make sense?

Also, I think there's a question about the general release of values
from multi-valued attributes. Should the starting point be "send
everything" or "send nothing"? If I understand the model from the web
page, the filter currently acts as a list of what to include, but it
sounds like from your examples, that in essence the default filter is to
send everything.

So if an admin sets a default ARP for Affiliation, a filter with each
value "checked" is created. Then within that, there's a flag that
controls whether the user can turn a checked value off for themselves.

Do I understand correctly?

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

Does this follow? If the default admin ARP set is a filter that says
release MEMBER (and include=Y), doesn't that mean that STAFF is not
checked in that case? Why would it be released unless the user
explicitly sets an ARP with a filter that includes it?

Contrast with the case where the admin does set a default ARP that
either has a default filter of send every affiliation, or explicitly
includes STAFF (with or without the include=Y flag). In that case, the
user would not need to do anything.

> > -- 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 why I think there's a sense in which the ACL can be on the
attribute and value. If I have permission to "control" the release of a
particular value, I guess that would mean I can set a default ARP for
any resource and any user that releases or excludes that attribute.
Whether it actually gets sent is of course dependent on whether any
given user actually has that attribute/value.

So for example in this case, I shouldn't have to explicitly do something
to the students in Chem101. If I "own" Chem101 for some period of time,
I should be able to say, for all users at OSU, release enrolledCourse
with a filter of Chem101 to some resource, and if a student that is in
Chem101 hits that URL, bingo. Everyone else has the policy set to
release it, but the AA knows they don't qualify.

See below...

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

This implies that an ACL also exists for the resource to allow me to set
ARPs for it. So perhaps my permissions are a union of control over
resources and attributes. If I own the resource, I can set policy about
any attribute. If I own the attribute, I can set policy about any
resource.

Does that work?

> - Admin creates a new ARP:Resource for ALL users in Chem101

I think the admin needs to be out of the loop on this. The admin, or
some process perhaps, should set an ACL so that Jane owns the Chem101
value. Then she can set the ARP herself (or a grad assistant can).

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

Again, she shouldn't have to do it for each one, or even have the system
do it for her underneath. She should just set an ARP for the resource
releasing it for everyone. Those who qualify release it, those that
don't won't be releasing it. The sanity check on what gets released is
always there in the AA (by way of the attribute implementations) at the
end.

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

This is roughly what I think Jane should be doing. So it's a matter of
delegating that right to her.

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

Yes, because entitlements are no different than courses. Same concept.
Somebody owns the value for some period of time.

> >      - presumably, we want the ARP manager to see a more user
friendly UI
> >      than having to enter this URN... what should that look like?

Assign a label to the URI and store it in metadata somewhere.

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

See earlier comment on that...if there's a filter that says release
MEMBER, doesn't that imply FACULTY isn't released unless a new filter is
set?

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

Think of entitlements as equivalent to courses with the difference that
the course concept has more institutional meaning and semantics. At
least, that's my opinion on it.

Feedback welcome. Complex, but I think we have the stuff on the table
finally.

-- Scott

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

    http://archives.internet2.edu/

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