shibboleth-dev - RE: Trust metadata for discussion
Subject: Shibboleth Developers
List archive
- From:
- To:
- Subject: RE: Trust metadata for discussion
- Date: Wed, 14 May 2003 13:39:19 -0400
At 11:12 AM -0400 5/14/03, Scott Cantor wrote:
> how would we deal with the situation where osu.edu has to be in both
groups/federations? (ie you'd like "regular" osu folks to be able to
access your local targets?)
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.....
> But, suppose you didn't want to do that.. and instead wanted to have
the osu origin in BOTH incommon and the osu federation.....
how would that affect your target side algorithms?
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?
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'll grant you -- it sounds very sensible. Once we start to see an explosion of federations, tho, I'm not sure how we could enforce this, or even how we would detect it.....
it might be easier to manage if its a specific origin-(target-application-domain) pairing.....
------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at
http://archives.internet2.edu/
------------------------------------------------------mace-shib-design--
- Trust metadata for discussion, Scott Cantor, 05/14/2003
- Re: Trust metadata for discussion, Steven_Carmody, 05/14/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/14/2003
- RE: Trust metadata for discussion, Steven_Carmody, 05/14/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/14/2003
- RE: Trust metadata for discussion, RL 'Bob' Morgan, 05/14/2003
- Re: Trust metadata for discussion, Walter Hoehn, 05/14/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/14/2003
- RE: Trust metadata for discussion, RL 'Bob' Morgan, 05/14/2003
- Re: Trust metadata for discussion, Walter Hoehn, 05/14/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/14/2003
- RE: Trust metadata for discussion, Steven_Carmody, 05/15/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/15/2003
- RE: Trust metadata for discussion, Steven_Carmody, 05/15/2003
- RE: Trust metadata for discussion, RL 'Bob' Morgan, 05/14/2003
- RE: Trust metadata for discussion, Steven_Carmody, 05/14/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/14/2003
- Re: Trust metadata for discussion, Steven_Carmody, 05/14/2003
Archive powered by MHonArc 2.6.16.