Shibboleth Developers

[Tom Scavo <>]

Howard, your solution on the SP side is the same solution one would
use on the IdP to integrate Shib with a local authn service (like CAS)
and IdP Discovery.  The SSO service redirects to the local authn
service, which redirects to the common domain cookie writing service,
which redirects back to the SSO service.  To make this happen, the
initial redirect has a target within a target just as you describe.

Is it ugly?  Hell, yeah, but it works! :-)  Is there a better way? 
Not without modifying the local authn service, which is seldom an
option.

Of course if authn and cross-domain SSO were integrated on the IdP
side (which as Scott has observed is staple fare in vendor products),
and the IdP managed its own server in the common domain (which is not
a given), then life is much simpler.  I suppose you could imagine a
similar "pie in the sky" simplification on the SP side...

Keep up the good work! :-)

Tom


On Thu, 11 Nov 2004 15:46:11 -0500, Howard Gilbert
<>
 wrote:
> 
> I have two problems that I am trying to solve. One comes from the
> CAS-Shibboleth paper where I was trying to figure out how to get the SHIRE
> to return through CAS before going to the Resource Manager.
> 
> The other comes from a complaint from Scott that, when the SHIRE is separate
> from the filter (if it is a Servlet in the /shibboleth application), he is
> unhappy about any technique that adds data to the original Resource query
> string.
> 
> To solve both problems, one can (and this would be an option configured in
> the Resource Manager Filter) encode the target= string so that the Browser
> makes one (or more) intermediate stop between the SHIRE and the resource. 
> 
>  ...
> 
> Encoding an already encoded string adds some processing and makes the string
> longer and uglier, but I don't think this is an important problem. There is
> an extra Redirect, but we have so many Redirects in the current path I have
> lost count. Is this a "cute" (bad) or an "elegant" (good) solution?