Shibboleth Developers

[Parviz Dousti <>]

Good example!  Here is how I have always been thinking about this:

	1- Unlike Resources, election of a SHAR is not based on "best fit".  It is 
either exact match or default.

	2- For the SHAR "chem101.osu.edu" there has to be a Default Resource which 
would be used if no match found on other URLs for this SHAR (case of your 
example).  The creation of that default can be forced by UI.

	3- To set up Defaults to handle your example one could have set up the 
default SHAR with at least 2 resources:
                URL: *.edu  -> Attr: Affiliation (All values)
                URL: *        -> Attr: Affiliation (MEMBER only)

Wouldn't this be enough?

Parviz

--On Friday, April 19, 2002 1:00 PM -0400 Scott Cantor <> 
wrote:

> Maybe this is because the discussions have tended to oversimplify some
> of the details, but I just want to clarify the way the AA is going to
> need to locate those policies. I'm not sure if I'm seeing a problem or
> not.
>
> Because of the wildcarding, you can't view the whole thing as strictly a
> tree, or a sequence of containers (SHAR, Resource, ...) or else you'll
> miss some. That might be why I had to think a while to understand it
> that way, since I tend to view things as relational when I'm designing
> (so I'm not an OO guy, sue me).
>
> Here's an example set of policies. Doesn't really matter whether they're
> admin or user-set.
>
> SHAR: *
>  URL: *
> Attr: affiliation=member
>
> SHAR: *.edu
>  URL: *
> Attr: affiliation (all values)
>
> SHAR: chem101.osu.edu
>  URL: http://chem101.osu.edu/syllabus/*
> Attr: entitlement=urn:mace:osu.edu:courses:chem101
>
> SHAR: chem101.osu.edu
>  URL: http://chem101.osu.edu/gradebook/*
> Attr: entitlement=urn:mace:osu.edu:courses:chem101
>          EPPN
>
> Now, say I access http://chem101.osu.edu/special/page.html
>
> What gets released? The correct answer is affiliation, based on the
> second ARP above.
>
> But you don't get that result if you follow the matching steps in a
> strict order, and check the SHAR first, before you check the URL. If you
> do that, you throw out the first two and only see the last two, since
> they match the SHAR exactly. Then you try the URLs and neither match, so
> you end up releasing nothing.
>
> My point is that you can't know whether the ARP matches just by looking
> at the SHAR, and since you can't know that, you can't throw any matching
> ARPs out for being less-specific matches until you go down a level and
> look at the URL.
>
> So the real process is to simultaneously match both SHAR and URL to get
> a matching set, and *then* you pick the best match for SHAR. That would
> give you the proper result above, since the matching set ends up being
> the first two, and you pick the second as a better match.
>
> Maybe this is already understood, but I wanted to make sure. I'm
> changing the AA section in the architecture to better explain all this,
> because I took out some of Marlena's verbose examples that did this and
> took out too much in the process.
>
> -- 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--