Initial Shibboleth Development
Peter Schober
peter.schober at univie.ac.at
Mon Sep 26 11:02:31 BST 2011
* Charlie Guo <crguo at stanford.edu> [2011-09-26 03:01]:
> getting started guides for Service Providers and I am currently following
> the instructions posted here:
> https://itservices.stanford.edu/service/shibboleth/sp/test-shib for setting
> up my application, and I already have some questions/problems. If anybody
> has answers for any of them, I would really appreciate it!
Note that you can always use the official Shibboleth documentation and
ask questions about it here.
> First, I didn't receive any security certs or keys back from testshib, and
> Stanford's instructions note that I should have received them and stored
> them in testshib.crt and testshib.key. Where can I find these, or do I not
> need them?
Any reason you're using testhib at all, when you could be using the
stanford IDP and your own SP?
Not sure aout the testshib thing, maybe the standford docs are
outdated? Isn't there documentation on the flow on the testshib site
itself?
You could also try using a different self-service SAML IdP,
https://openidp.feide.no/
> Second, the application is running Django, and using mod_wsgi to
> route the urls. Is there a resource that I should be Aliasing
> /Shibboleth.sso to?
No, quite the contrary: you'll need to ensure that the Shibboleth SP's
handlerURL ("/Shibboleth.sso" by default) is not handled by your
application, so In some cases it might still be necessary to re-assign
this URL (and everything below) to mod_shib.
> # Tell Apache to load the Shibboleth Metadata
> #
>
> Alias /Shibboleth.sso/Metadata "/etc/shibboleth/shibboleth2.xml"
This is nonsensical for a couple reasons. The Shib SP services up it's
own metadata on that exaclt location by default (for quite some time
now). And if you had a working SP everything below /Shibboleth.sso
would be handled by mod_shib anyway. And without a working handlerURL
the software will not work at all.
Also if you want to exchange metadata it's advisable to simply get a
copy of the IdP's (and SPs's) metadata and stick it into the SP (and
IdP), via local files. ALso allows you to easily modify and tune those
metadata files, in case you need to.
> <Location /stanford/shibboleth >
> AuthType shibboleth
> ShibRequireSession On
> ShibUseEnvironment On
> Require user
> </Location>
>
> <Location /secure>
> AuthType shibboleth
> ShibRequestSetting requireSession 1
> require valid-user
> </Location>
These latter is just an example, which you can remove or adjust to
taste. Protect what you /need/ to protect, not what the example says.
Also, "ShibUseEnvironment" is the default (so specifying it help does
nothing for you) and "ShibRequireSession On" is the old way of saying
"ShibRequestSetting requireSession 1".
So wherever you got those things from, it buys you nothing over using
the supplied example and adjusting the <Location> directive to your
application's needs.
> Third, I'm running into an error message "Error Message: SAML 2 SSO profile
> is not configured for relying party 'https://dev.classowl.com/shibboleth-sp'".
> The TestShib portal was working previously but now has stopped working. I'm
> not sure which file I changed to create the problem.
testshib gives you access to it's log files, so use them. This shoud
also be listed in the common errors in the troubleshooting section of
the documentation.
-peter
More information about the users
mailing list