Hi
Anyone with a vague interest in getting the SP going to protect local applications might have been following my own fumblings that I've posted here (that means none of you? right?)
I'm posting this here in case anyone coming along after falls into the same holes I have!
If you have a web server which serves some pages as http and some as https which you need to protect with the shibboleth SP you have a problem. The trouble is: if you put in place metadata with https URLs, as soon as you access an http:// web page it wants to use an http:// ACS and the login fails with the "no peer endpoint" message. You could edit the metadata and put in a duplicate set of ACS urls with http:// in them but that seems awful messy to me.
As an aside, it has been argued that what you get from https://mysite/Shibboleth.sso/Metadata is just an example and should not be used as is. So far I personally have found no need to change what you get out from that and it seems perfectly acceptable to me.
In the shibboleth2.xml <Sessions> section, you can put the directive
handlerSSL= "true"
which forces all of the ACS traffic to https and makes this work whether you're visiting an http or https site. [1]
But:
It has been argued that going to an http:// site will result in your cookies being exchanged unencrypted. Now, we've been talking about this here in Dundee and we aren't convinced its as scary as its made out to be. Sniffing a cookie going across the wire will generally be very difficult - I'm not even sure how you could tap into it on campus, and even if it is captured we think it can only be used to spoof the current session. But, it is something we should be aware of, should the login be performed at an insecure location such as an internet cafe.
So to make sure our cookies are sent encrypted we put cookieProps="; path=/; secure" also in the <Sessions> element. So now we have:
<Sessions lifetime="28800" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="true" cookieProps="; path=/; secure"
But, As Peter pointed out:
"But on a site available over both https and plain http you cannot set
cookieProps="; path=/; secure" in the Sessions element since then
you'd only cause looping (marking the Shib cookies as secure, but
allowing access to the site on plain http will lead to the user agent
to not send the secure cookie, hence mod_shib's protection would kick
in, thinking there is no session yet, send to the IdP, etc.pp, ad lib.)"
Your browser can't send cookies to the SP because it insists they come over https and you're only doing http to it, so it never gets the session cookie and what you see is a never ending set of new sessions being created in shibd.log
2010-06-02 15:47:19 INFO Shibboleth.SessionCache [1]: new session created: ID (_69642bd355d7a10f8756dba073ab7b7e) IdP (https://idptest.dundee.ac.uk/shibboleth) Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (134.36.40.227)
2010-06-02 15:47:20 INFO Shibboleth.SessionCache [1]: new session created: ID (_392d83f33c5bffad55c792670b46da08) IdP (https://idptest.dundee.ac.uk/shibboleth) Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (134.36.40.227)
2010-06-02 15:47:20 INFO Shibboleth.SessionCache [1]: new session created: ID (_02ebba0aa84960f69322c9151a1f011a) IdP
...
and the browser flickering between http and https as it bounces you round backwards and forwards between the IdP and the SP, ad nauseam (or ad "until you get fed up and close the browser") [2]
So, to get your cookies transferred encrypted you _have_ to force everything to https. (Isn't this where we started by saying that there are some web sites already setup to do some stuff https but some just http?). The SP configuration itself can be used to force this though, so the site doesn't need changing- we can do it for them. If we add redirectToSSL ="443" to the shibboleth2.xml RequestMap element, i.e.:
<RequestMapper type="Native">
<RequestMap applicationId="default" redirectToSSL ="443">
[3]
We can force it for the whole site. This can also be done on a per web page basis in .htaccess by adding
shibRequestSetting redirectToSSL 443
to the apache .htaccess file [4], but of course that needs to be done everywhere you want to access with http: if you have the cookieprops setting above.
Sorry if I'm teaching my "grandmother to suck eggs" and everyone else has already sussed all this out. If there's anyone who is about to go down this route I hope I've saved you some of the messing around I've had, it hasn't always been easy to find the "right bit of documentation" (strange, it seems very easy now....)
Cheers
Andy
[1] https://spaces.internet2.edu/display/SHIB2/NativeSPSessions
[2] https://spaces.internet2.edu/display/SHIB2/NativeSPLooping
[3] https://spaces.internet2.edu/display/SHIB2/NativeSPRequestMapper
[4] https://spaces.internet2.edu/display/SHIB2/NativeSPApacheConfig
************************************************************
Please consider the environment. Do you really need to print this email?
The University of Dundee is a registered Scottish charity, No: SC015096
|