Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Wed, 14 May 2003 

 wrote:

> >If there's no overlap in CAs, then the osu.edu origin has to know
> >which key to use to sign based on the target. The obvious way to
> >do that is to duplicate the HS and the AA entry points and
> >configuration, which is trivial with J2EE and Apache.
> >
> >I see that as a good solution, not a workaround.
>
> ahhh... that's probably what I meant by the phrase "operating a
> second AA"... sorry I didn't describe it very accurately.....

So, to restate this so I can test my understanding:  if an origin needs to
support distinct requirements of targets (eg what key/cert to use to sign
an authn assertion), then it has to run distinct HS/AA instances, which
specifically means distinct service URLs, aka entry points.  Seems
reasonable to me, and as we've discussed, its acceptability depends
somewhat on how many federations show up in practice.

> >The target algorithms only apply after a POST. The starting point is
> >the WAYF, and it will direct the user on behalf of the target
> >to the right place. If my target trusts InCommon osu.edu but not OSU
> >osu.edu, then it needs to use a WAYF that will send OSU users
> >to the InCommon HS URL.
>
> well, let's start there, with the WAYF -- if the target is in two
> federations, how does it know which WAYF to send the user to? present
> the user with a list, and let them choose?

As we know, there might not even be a WAYF.  A target can offer its own
list of origins, or its own list of federations, from which the user is
expected to choose, and it can employ various means to narrow or
default the list.  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.

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.

> >The limitation is that any given target has to know unambiguously
> >which federation an origin site is in from its point of view. I
> >don't see that as a big deal. Anything else is just asking for
> >confusion. Federations are not "per-request-context" and they
> >shouldn't act like it.
>
> OK -- so there we have a groundrule.... we have multiple
> federations. Targets are in multiple federations. Origins are in
> multiple federations. But a specific origin-target pairing can only
> be in one federation?

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", but it seems to me
the only rule is that the target is responsible for directing the incoming
unauthenticated user to either the appropriate origin or the 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).  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.

 - RL "Bob"


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

    http://archives.internet2.edu/

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