<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Any pointers on where I can read more about this?<br> > I
did implement the ability to choose an entityID based<br> > on the entityID of
the IdP, but that's the closest.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The IdP entityID will be static, and it only applies to the one connection, so if that will help to solve it, I'd like to explore it.<br>
</div><div class="gmail_quote"><br><br>On Thu, Jul 25, 2013 at 1:39 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On 7/25/13 1:10 PM, "Brian Mathis" <<a href="mailto:brian.mathis@gmail.com">brian.mathis@gmail.com</a>> wrote:<br>
<br>
>I have setup my apache config to request the alternate application, but<br>
>it seems to have no effect:<br>
<br>
</div>You failed to ensure there's a handler also mapped to the override. You<br>
appear to be attempting path-based overrides. This is much harder to do,<br>
but you need a complete Sessions element in the override with a handlerURL<br>
that maps to the override, probably /shibboleth/Shibboleth.sso I suppose,<br>
in this case.<br>
<div class="im"><br>
>This also would be a problem, since then I would always be using the<br>
>alternate application configuration.<br>
<br>
</div>I can't decide how to lay it out, I don't know precisely what your<br>
requirements are. Using generic paths like /shibboleth is probably not a<br>
great idea, obviously, so that probably isn't what you want.<br>
<div class="im"><br>
>it seems that any application override must also use completely separate<br>
>paths (without creating a new virtualhost)?<br>
<br>
</div>No, they should use a vhost only, and not paths. That's the advisable<br>
approach for overrides, but is not really targeted at your use case. Using<br>
a vhost might be overkill here, I don't know.<br>
<br>
If you use one vhost and then use paths mapping to different applications,<br>
then you must reserve and set a handlerURL base location that will map<br>
into the override and that will be the SAML endpoint the IdP uses.<br>
<div class="im"><br>
>If so, then the explanation of the example is really misleading as it<br>
>seems to be a very simple thing, while it actually involves a lot of<br>
>other config changes as well.<br>
<br>
</div>I don't know what example you're referring to. Doing vhost-based overrides<br>
is reasonably simple. Doing path-based is not.<br>
<br>
All of them are some degree of work because even a "simple" vhosted<br>
override will involve additional metadata work and possibly Apache work.<br>
<div class="im"><br>
>OK, so after all of that, given my requirements, is there a way to create<br>
>a simple alias for an entityID, or to specify an alternate/additional<br>
>audience that would be acceptable?<br>
<br>
</div>There is no way to create a simple alias, no. SAML has no such concept. I<br>
did implement the ability to choose an entityID based on the entityID of<br>
the IdP, but that's the closest.<br>
<br>
The override mechanism can, with work, accomplish such a thing, but at the<br>
cost of aliasing *resources*, and it isn't particularly elegant since it's<br>
not geared to solve that problem.<br>
<br>
With respect to overrides, the simplest way is to use vhosts to do the<br>
override, because the handler behavior is essentially automatic.<br>
<br>
The hardest approach is path-based within a vhost.<br>
<br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br></div></div>