[Shib-Users] SP Protection of both SSL and non

Ian MacDonald

unread,

Apr 1, 2010, 1:12:59 PM4/1/10

to shibbole...@internet2.edu

I have a basic SP protecting a web page /secure, and I have it setup for
both an SSL and non-SSL vhost; I attached it here stripping non-relevant
bits about logs,etc.

<VirtualHost *:80>
ServerName sp.example.org
<Location /secure>
AuthType shibboleth
ShibRequestSetting requireSession 1
# ShibRequestSetting applicationId default
require valid-user
</Location>
<Location /shibboleth-sp>
Allow from all
</Location>
Alias /shibboleth-sp/main.css /usr/share/shibboleth/main.css
Alias /shibboleth-sp/logo.jpg /usr/share/shibboleth/logo.jpg
</VirtualHost>
<VirtualHost *:443>
ServerName sp.example.org
SSLEngine On
SSLCertificateFile /etc/ssl/certs/sp.pem

<Location /secure>
AuthType shibboleth
ShibRequestSetting requireSession 1
# ShibRequestSetting applicationId default
require valid-user
</Location>
<Location /shibboleth-sp>
Allow from all
</Location>
Alias /shibboleth-sp/main.css /usr/share/shibboleth/main.css
Alias /shibboleth-sp/logo.jpg /usr/share/shibboleth/logo.jpg
</VirtualHost>

Right now, the Shib module only seems to protect
http://sp.example.org/secure
and not
https://sp.example.org/secure

I figure this must have to do with overrides in shibboleth2.xml where I
have added hosts to requestmapper to try and include the https site also

They should both be covered by the same "default" applicationID, so I am
not sure where else to configure the second vhost on 443 to protect it
with Shib.

I originally expected both to be covered based on the AuthType in the
vhost. The second Host name in RequestMapper did not have the intended
effect, so I suspect is actually not even necessary as shown below.

Although I think it only applies to IIS (per comments in xml file), I have also created matching entries in the
InProcess section for both sites.

Is is considered okay to have both the protected service and the SP Bindings operating on both SSL and non-SSL and share the same domain space.

For all my SP config I have been referencing https://sp.example.org/shibboleth and have handlerSSL="true" in my <Sessions> config.

cheers,
Ian

Peter Schober

unread,

Apr 1, 2010, 1:30:47 PM4/1/10

to shibbole...@internet2.edu

* Ian MacDonald <im...@netstatz.com> [2010-04-01 19:14]:

> I figure this must have to do with overrides in shibboleth2.xml where I
> have added hosts to requestmapper to try and include the https site also

With Apache httpd you don't need to touch the requestmap at all.

> Although I think it only applies to IIS (per comments in xml file),
> I have also created matching entries in the InProcess section for
> both sites.

With Apache httpd you don't need to touch the InProcess at all.

Are you just trying to push all the knobs you can possibly find?
How about just trying
https://spaces.internet2.edu/display/SHIB2/NativeSPGettingStarted

> Is is considered okay to have both the protected service and the SP
> Bindings operating on both SSL and non-SSL and share the same domain
> space.

Yes.

> For all my SP config I have been referencing
> https://sp.example.org/shibboleth and have handlerSSL="true" in my
> <Sessions> config.

OK.
You'll want to make sure all ACS URLs in the SP's metadata will only
include https endpoints (things will work either way, but browser
warnings will ensue when HTTP POSTing from https/IdP to http/SP).
Unless you explicitly set the shib cookies to be flagged "secure" they
can be read by both ssl and non-ssl vhosts, even though they're being
set only in the ssl-vhost (otherwise you'd probably be looping).
-peter

Michael J. Wheeler

unread,

Apr 1, 2010, 1:38:18 PM4/1/10

to shibbole...@internet2.edu

On 4/1/2010 12:30 PM, Peter Schober wrote:

> Are you just trying to push all the knobs you can possibly find?

One would hope not; that would seem like an exercise in frustration.
Traditionally knobs are turned and buttons are pushed. But, I guess you
could have a knob with an integrated button that you turn to the desired
setting and push to "apply" it. :)

> How about just trying
> https://spaces.internet2.edu/display/SHIB2/NativeSPGettingStarted
>

--
Michael J. Wheeler
Assistant Director, Systems and Networking
Pittsburg State University
Phone: 620-235-4610
E-mail: mwhe...@pittstate.edu

Scott Cantor

unread,

Apr 1, 2010, 1:39:29 PM4/1/10

to shibbole...@internet2.edu

> Right now, the Shib module only seems to protect
> http://sp.example.org/secure and not https://sp.example.org/secure

Your Apache configuration is to blame (I don't know why, I'm just telling you where to look).

> I figure this must have to do with overrides in shibboleth2.xml where I
> have added hosts to requestmapper to try and include the https site also

Use either Apache or the RequestMap, but not both. Preferably Apache, it's simpler and safer for most people.

> I originally expected both to be covered based on the AuthType in the
> vhost. The second Host name in RequestMapper did not have the intended
> effect, so I suspect is actually not even necessary as shown below.

It's bogus anyway, you're putting a URL into an attribute for specifying a hostname.

> <Host name="sp.example.org">

correct (and implies both default ports on http and https)

> <Host name="https://sp.example.org">

not correct

> Is is considered okay to have both the protected service and the SP Bindings
> operating on both SSL and non-SSL and share the same domain space.

Functionally it is, but consider the effort of protecting a web site only to create a session that's secured with a cookie sent over the net in the clear. "Why bother" comes to mind for me.

Peter noted the other considerations.

-- Scott

Peter Schober

unread,

Apr 1, 2010, 1:43:49 PM4/1/10

to shibbole...@internet2.edu

* Ian MacDonald <im...@netstatz.com> [2010-04-01 19:14]:

> <VirtualHost *:80>
> ServerName sp.example.org

Try http://sp.example.org:80

> <VirtualHost *:443>
> ServerName sp.example.org

and https://sp.example.org:443 here.

And you don't need to touch the RequestMap (as I said before) but
since there's an error there I might as well mention that:

> <RequestMap applicationId="default">
> <Host name="sp.example.org">
> <Path name="secure" authType="shibboleth" requireSession="true"/>
> </Host>
> <Host name="https://sp.example.org">
> <Path name="secure" authType="shibboleth" requireSession="true"/>
> </Host>
> </RequestMap>

Specifying the scheme inside the <Host>'s name attibute is not valid.
There's the optional scheme (and port) attribute, see
https://spaces.internet2.edu/display/SHIB2/NativeSPRequestMapHost

For your non-ssl vhost not being protected there's:
https://spaces.internet2.edu/display/SHIB2/NativeSPWontProtect

(a child page of
https://spaces.internet2.edu/display/SHIB2/NativeSPTroubleshootingTactics
which is a child page of
https://spaces.internet2.edu/display/SHIB2/Troubleshooting )

cheers,
-peter

Peter Schober

unread,

Apr 1, 2010, 1:45:49 PM4/1/10

to shibbole...@internet2.edu

* Michael J. Wheeler <mwhe...@pittstate.edu> [2010-04-01 19:39]:

>> Are you just trying to push all the knobs you can possibly find?
>
> One would hope not; that would seem like an exercise in frustration.
> Traditionally knobs are turned and buttons are pushed. But, I guess you
> could have a knob with an integrated button that you turn to the desired
> setting and push to "apply" it. :)

That wouldn't have happened to me in my native language (or had I
taken the time to write this more carefully).

Maybe I should just answer questions in German.
-peter

Peter Schober

unread,

Apr 1, 2010, 2:40:12 PM4/1/10

to shibbole...@internet2.edu

Mamelad.

* Peter Schober <peter....@univie.ac.at> [2010-04-01 19:45]:

> * Ian MacDonald <im...@netstatz.com> [2010-04-01 19:14]:
> > <VirtualHost *:80>
> > ServerName sp.example.org
>
> Try http://sp.example.org:80
>
> > <VirtualHost *:443>
> > ServerName sp.example.org
>
> and https://sp.example.org:443 here.

Des is a Topfn, w�u da easte Vauhost is eh von vuanharein so und da
ondare gehd eh. S'woa scho a longa Tog und i vuahin am Sprung.
Oiso des Oware ignorian.

Seavas,
-peter

Note: Ostmittelbairisch deviations from standard German apply
(Strictly speaking German is not my mother tongue either ;)

Ian MacDonald

unread,

Apr 1, 2010, 3:42:02 PM4/1/10

to shibbole...@internet2.edu

So I have performed some cleanup based these notes,

still the same result; But I believe I need to fix my vhost config,
though it is not obvious why it is not working to me.

These results show that each aspect (protection, location resolution,
shib SP) works in one context, but not both; this should be solvable
thought the vhosts are identical, save port reference. Perhaps it is
their *:443 *:80 nature as Scott suggests in another email.

http://sp.example.org/secure (protected)
https://sp.example.org/secure (unprotected)

http://sp.example.org/shibboleth-sp/logo.jpg (works, shows shib logo)
https://sp.example.org/shibboleth-sp/logo.jpg (not found)

http://sp.example.org/Shibboleth.sso/Status (not found)
https://sp.example.org/Shibboleth.sso/Status (shows Shib SP status)

On Thu, 2010-04-01 at 19:30 +0200, Peter Schober wrote:
> With Apache httpd you don't need to touch the requestmap at all.

Okay, so I assume then in my vhost I need to uncomment the following in
order to make the association to the "default" applicationID, which
otherwise is determined by <RequestMap> <Host>.

# ShibRequestSetting applicationId default

If I comment out the entire <RequestMap applicationId="default">
section, when I start shibd, I see

ilum:~# /etc/init.d/shibd start
shibd error: unable to run config check as user
Starting Shibboleth 2 daemon: shibd.

So instead, I just commented out all the host sections. I like
protecting specific resources, rather than the entire namespace
sp.example.org which is shared by all the binding context locations.

In fact thinking about it, am I inadvertently protecting SP ACS URLs?

> With Apache httpd you don't need to touch the InProcess at all.

Right, I just commented the ISAPI section out.

> Are you just trying to push all the knobs you can possibly find?

No, I think my initial failure to get a vanilla config between IdP and
SP based on metadata shortcomings took me inward to try and understand
more of the knobs, and then to specify working parameters over commented
examples in some cases.

> How about just trying
> https://spaces.internet2.edu/display/SHIB2/NativeSPGettingStarted

I did start way back here..

My default Application is attached below for reference; It doesn't solve
my somehow unprotected https page, despite the vhost AuthType reference
and applicationID reference in the vhost.

> > For all my SP config I have been referencing
> > https://sp.example.org/shibboleth and have handlerSSL="true" in my
> > <Sessions> config.
>
> OK.
> You'll want to make sure all ACS URLs in the SP's metadata will only
> include https endpoints

Mine appear to be correct in this respect, shown below from my metadata
file.

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.example.org/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://sp.example.org/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sp.example.org/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://sp.example.org/Shibboleth.sso/SAML2/ECP" index="4"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://sp.example.org/Shibboleth.sso/SAML/POST" index="5"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://sp.example.org/Shibboleth.sso/SAML/Artifact" index="6"/>

cheers,
Ian

Application_Default follows:

<md:SingleLogoutService Location="/SLO/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

<md:ManageNameIDService Location="/NIM/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

<md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

<Handler type="Status" Location="/Status"/>

</Sessions>

</ApplicationDefaults>

Ian MacDonald

unread,

Apr 1, 2010, 3:42:09 PM4/1/10

to shibbole...@internet2.edu

> > Is is considered okay to have both the protected service and the SP Bindings
> > operating on both SSL and non-SSL and share the same domain space.
>
> Functionally it is, but consider the effort of protecting a web site
> only to create a session that's secured with a cookie sent over the
> net in the clear. "Why bother" comes to mind for me.

This I understand.

As soon as I can get the https protected, I am just going to turn off
the http or forcefully redirect.

Ian MacDonald

unread,

Apr 1, 2010, 3:42:21 PM4/1/10

to shibbole...@internet2.edu

On Thu, 2010-04-01 at 19:43 +0200, Peter Schober wrote:

> Specifying the scheme inside the <Host>'s name attibute is not valid.
> There's the optional scheme (and port) attribute, see
> https://spaces.internet2.edu/display/SHIB2/NativeSPRequestMapHost
>
> For your non-ssl vhost not being protected there's:
> https://spaces.internet2.edu/display/SHIB2/NativeSPWontProtect
>
> (a child page of
> https://spaces.internet2.edu/display/SHIB2/NativeSPTroubleshootingTactics
> which is a child page of
> https://spaces.internet2.edu/display/SHIB2/Troubleshooting )
>

Thanks, I'll give all these a read if I have not already

cheers,
Ian

Ian MacDonald

unread,

Apr 1, 2010, 3:55:36 PM4/1/10

to shibbole...@internet2.edu

On Thu, 2010-04-01 at 15:42 -0400, Ian MacDonald wrote:
> These results show that each aspect (protection, location resolution,
> shib SP) works in one context, but not both; this should be solvable
> thought the vhosts are identical, save port reference. Perhaps it is
> their *:443 *:80 nature as Scott suggests in another email.
>
> http://sp.example.org/secure (protected)
> https://sp.example.org/secure (unprotected)
>
> http://sp.example.org/shibboleth-sp/logo.jpg (works, shows shib logo)
> https://sp.example.org/shibboleth-sp/logo.jpg (not found)
>
> http://sp.example.org/Shibboleth.sso/Status (not found)
> https://sp.example.org/Shibboleth.sso/Status (shows Shib SP status)
>

Pretty obvious once I looked at my own email,

I have two VirtualHosts .. and I missed the nice warning from apache2.

[warn] _default_ VirtualHost overlap on port 443, the first has
precedence

I simply forgot to add NameVirtualHost *:443 in addition to Listen 443
to my httpd.conf.

The fact that the Status message was displaying on SSL confused me, but
this somehow still worked since the shib module is operating across the
entire server, so this was the _default_ vhost, not my configured one
responding; hence the not found on actual Location paths. I hope this
becomes the root of all my *metadata* issues.

Scott Cantor

unread,

Apr 1, 2010, 4:14:16 PM4/1/10

to shibbole...@internet2.edu

> Okay, so I assume then in my vhost I need to uncomment the following in
> order to make the association to the "default" applicationID, which
> otherwise is determined by <RequestMap> <Host>.

No. Everything is "default" unless it's something else, so there is never a case where specifying that is needed, short of a weird need to carve out a subtree inside a non-default app as part of the default app.

> So instead, I just commented out all the host sections. I like
> protecting specific resources, rather than the entire namespace
> sp.example.org which is shared by all the binding context locations.

<Path> can only live inside <Host>. What you protect is up to you, but the map syntax isn't.

> In fact thinking about it, am I inadvertently protecting SP ACS URLs?

Understandable question, but that's prevented automatically. Handlers always bypass the rest of the logic, which is why they're all prefixed with a common base path. Individually they could be implemented so as to require access to a session (e.g. the Session handler) but that’s done in the handler code, not by relying on the usual request processing.

-- Scott

Reply all

Reply to author

Forward

[Shib-Users] SP Protection of both SSL and non_SSL vhosts

Ian MacDonald

Peter Schober

Michael J. Wheeler

Scott Cantor

Peter Schober

Peter Schober

Peter Schober

Ian MacDonald

Ian MacDonald

Ian MacDonald

Ian MacDonald

Scott Cantor