Shibboleth Developers

[Scott Cantor <>]

> If the result is that the user has indicated "osu.edu" and 
> the target doesn't know which fedaration to choose, then 
> either the user will have to be offered a choice or the 
> target will have to pick one.

That's definitely true, but if the target has delegated to a WAYF, then if 
OSU is reachable from two different fed WAYFs, the target
can't know in advance which one to use for the user if it only trusts OSU by 
way of one of them. But...

> I just don't think this will be a problem in practice.  
> People figuring out how users will interact with their 
> targets will require it to be usable, and will naturally 
> limit policy conflicts like this.

Probably true.

> I'm sorry, but as you point out, Steven, a rule like this is 
> entirely unrealistic.  I'm not sure what you mean, Scott, by 
> "Federations are not 'per-request-context' and they shouldn't 
> act like it",

What I meant was that for a given target and origin, I don't want to see the 
code impacted to some huge degree by having to do
different things all over based on which federation was "in play" at the 
time. We don't have the hooks in the code for that once you
get the session going. But I don't see a way out of that at this point. AAP 
policy is one case, since a Site in one federation could
have different Domains listed from the same Site in a second, not to mention 
CAs.

If the rule I was positing is unrealistic, then the current code is broken, 
because the target uses the origin site as the input to
get trust and policy data. If the same origin site can lead to multiple sets 
of data, it won't work as is. Additionally, it would be
wrong to use the union of the two sets of CAs, since for a given interaction, 
which one is valid should be unambiguous.

So the way out I see is to expand the API to treat the Federation URI as part 
of the discrimination process along with the origin
site. Then I can locate the right trust information for *that interaction*, 
and I can get that from the Audience.

> appropriate WAYF.  Perhaps the implication here is that 
> targets with complicated relationships with origins and 
> federations will require additional metadata to represent 
> these relationships; it seems to me that any such metadata 
> will also have to include representations of the target 
> resources (eg, this section of the site is associated with 
> this federation-set, etc).

Well, all I was hoping to avoid was a need to duplicate policy. If I want to 
write a rule about psu.edu, I'd rather not have to do
it over again for each shared federation we happen to be in.

OTOH, if the federation is really properly part of that policy anyway, then 
we probably should just dump the idea of using DNS
domain names for sites, and just go the URI route. We're pretty much able to 
do that now, since the site name is more or less just
used as a key for lookup. Then each origin has a new URI per federation, and 
all the policy is obviously per-fed.

> Obviously we can't build this in 
> the general case.  I think we should avoid scope-creep on the 
> sites file trying to deal with this issue, which I think is 
> what's happening here.

Well, so far, I've presented a first draft that requires:

a) one sites file
b) one fed per origin site per target

Walter asked about (a), and you and Steven appear reluctant to agree to (b). 
(b) is effectively the current state in 0.8, since the
code really only deals with one set of trust material, and uses origin site 
alone as a policy lookup.

So I don't see scope creep so much as a basic fleshing out of requirements.

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