Shibboleth SP browser loops when attempting to connect to protected site

[Nate Klingenstein]

Bryan,

You should think of the problem as two pieces: first the user shows up at the SP with an assertion from the IdP that needs to be processed by Shibboleth, and then the user is given a session and sent to the protected resource, e.g. the application.  The first half happens under /Shibboleth.sso, while the resource itself is responsible for issuing the ultimate response.  The configuration you're using touches both, but the host name and path below would require a Shibboleth session for scheme://IOMETER1.KAYACORP.COM:port/EmpWeb* .  That won't be connected to the things done under the /Shibboleth.sso tree.

You may find this article helpful:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication

Hope this helps,
Nate.

On Aug 8, 2014, at 12:51 PM, String76 <hortonb at kayacorp.com<mailto:hortonb at kayacorp.com>>
 wrote:

Sorry about the last reply.  Did not intend to reply without adding more details.  In the host section I was under the impression the Path name should be set to the site/application you want to protect?  EmpWeb is an application under the ShibTest site.  I thought that for Shib to work I had to point to https://iometer1.kayacorp.com/EmpWeb/Shibboleth.sso.  Sounds like I am completely wrong here?

            <Host name="IOMETER1.KAYACORP.COM<http://IOMETER1.KAYACORP.COM>">
                <Path name="EmpWeb" authType="shibboleth" requireSession="true"/>
            </Host>


From: Cantor, Scott E. [via Shibboleth] [mailto:[hidden email]<x-msg://7303/user/SendEmail.jtp?type=node&node=7605207&i=0>]
Sent: Friday, August 08, 2014 12:31 PM
To: Bryan Horton
Subject: Re: Shibboleth SP browser loops when attempting to connect to protected site

I can identify a number of obvious mistakes.

- your <Site> element's name contains a URL, which is not allowed, that's
a hostname only
- you should not set port or scheme there unless you are actually
virtualizing them; if they match what the physical request would determine
they should be, then don't set them

>My setup is a Windows 7 test system with IIS 7.5 and a web applications
>configured for SSL only.  Shibboleth 2.5.3 is installed to the default
>location.  My current shibboleth2.xml file is attached. My idP is VMware
>Horizon Workspace Portal 2.0 which supports SAML 2.0.  Within Workspace I
>have configured a web app to point to
>https://iometer1.kayacorp.com/EmpWeb/Shibboleth.sso/SAML2/POST as the ACS
>URL.

You should really not do that, those handlers should be at the root, buf
if you insist on doing that, then you're going to have to change the
default handlerURL to "/EmpWeb/Shibboleth.sso".

I'm not sure you want or need to do that, however.

>  Note that in the xml file in the MetadataProvider section I have
>commented out the filter for the certificate.  When I included this line
>with either a crt or pem the shibd.log would would error saying the
>metadata
>source is not signed (the iDP does have a SAML certificate and this is
>what
>I exported into a pem file).

How you deal with metadata is a local decision, but you need a secure
source of it, and nobody else can tell you what settings to use unless
you're using an existing federation that has standing practice about how
to consume its metadata.

If the metadata's not signed, then you'd better not be pulling it from a
remote source, and you certainly can't enforce a signature over it, no.

>Also, I have read through several posts about redirect loops and have
>tried
>playing with the cookieProps setting but keep getting the same results.
>Hopefully someone can point me in the right direction here and tell me
>where
>I messed thing up?

Loops are a wholly local matter to fix, but until you correct the major
mistakes, it's not worth worrying about it much.

If /Shibboleth.sso wasn't mapped at the root, you couldn't get a loop. So
maybe you're just confused about that entirely. Why do you think you need
to mount it below a subdirectory? You don't appear to have done that, and
it doesn't appear that you need to.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]<x-msg://7303/user/SendEmail.jtp?type=node&node=7605204&i=0>

________________________________
If you reply to this email, your message will be added to the discussion below:
http://shibboleth.1660669.n2.nabble.com/Shibboleth-SP-browser-loops-when-attempting-to-connect-to-protected-site-tp7605202p7605204.html
To unsubscribe from Shibboleth SP browser loops when attempting to connect to protected site, click here<x-msg://7303/>.
NAML<http://shibboleth.1660669.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

________________________________
View this message in context: RE: Shibboleth SP browser loops when attempting to connect to protected site<http://shibboleth.1660669.n2.nabble.com/Shibboleth-SP-browser-loops-when-attempting-to-connect-to-protected-site-tp7605202p7605207.html>
Sent from the Shibboleth - Users mailing list archive<http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html> at Nabble.com<http://Nabble.com>.
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140808/bce92825/attachment.html