Shibboleth Developers

[Walter Hoehn <>]

RL 'Bob' Morgan wrote:
> 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.

I don't think this necessarily means multiple instances of the HS/AA.  A 
single instance could listen on different URLs and map different 
handlers to these URLs.

1. Target or WAYF decides which origin (represented by a URL) to 
re-direct to.

2. The origin listens on multiple URLs, receives a request, then 
constructs a response based on which URL the request came in on.  The 
Audience is set appropriately.

3. The SHIRE passes the hs name and audience to the OriginMapper and 
gets back a trust store.

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

ditto.

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

I think the main idea here is just to make configuration simpler, ie: 
getting rid of the step where you grab a bunch of certs and stick them 
in 3 different places".


--
-------------------------
Walter F. Hoehn, Jr
Systems Programmer
Columbia University - EPIC
-------------------------

Attachment: pgpHYr9j6ATVh.pgp
Description: PGP signature