As a before_filter, the system makes use of #logged_in? To determine
if a current user could be found. That code is a simple !!
current_user;

Now, shibboleth adds fields to the request headers of all incoming
traffic. Instead of doing the logged_in filter, we just set something
up to create or find a database record that corresponds to the user.
This looks like this (For the shib variable ‘eppn’), assuming that
your User table has a field named eppn.

That’s it! Of course, you’re going to need a way to ensure that
database record is meaningful in the context of your application - In
our situation, we test for the presence of contact information and
then prompt the user to add it if none exists, but it doesn’t really
matter because the data in our IP to DNA lookup table is sorted by
their eppn anyway.

Thanks for the response Alex, to be honest I’m getting in a muddle
trying to figure out how this works / fits together, but I’m picking up
bits and pieces here and there. I’ll take a look at RESTful
authentication and have a play.

Can I check I understand this right? From what I understand the user
tries to access and Shibboleth restricted resource, Apache redirects the
user away to the Identity Provider to authenticate themselves and then
when they are redirected back Apache adds this additional header to each
subsequent request to Mongrel? Or is it a header that is added by the
client and sent through with each subsequent request until they are
logged out?

I guess your application deals with the user once they are already
authenticated and that work is done outside of they rails app. Do you
have any sample configuration for the Shibboleth setup? I’ve seen
something called saml2ruby which has been used to interface with the
service provider directly, and I guess setting those headers in another
way its not greatly documented and I guess not required if Apache can do
everything for you.

Is this just for Apache, I think this client uses Nginx and that might
be a problem?

Thanks for the response Alex, to be honest I’m getting in a muddle
trying to figure out how this works / fits together, but I’m picking up
bits and pieces here and there. I’ll take a look at RESTful
authentication and have a play.

Some concepts may be useful, but please don’t ever use that piece of
garbage in your application (it relies too much on generated code). You
may find it useful to compare how Authlogic does things.

I think at this point, the Shibboleth Service Provider itself only
supports Apache and IIS. The integration is straightforward with those
servers. For rails specific authorization, plugging Shibboleth and
Passenger into Apache makes authentication pretty straightforward.

Best Regards,

The problem with rack-saml https://github.com/toyokazu/rack-saml and
similar is that they don’t support encrypted responses. I ran into this
issue while trying to work with an IdP and encryption enabled (the
encryption was a requirement).

My stack was nginx (1 server frontend) + passengers (multiple servers).
I
tried lots of solutions but I ended up with shibd and Apache web server.

So, shibd + Apache and a little shib.php file that would grab whatever
shibd environment there is after successful authentication, put it in a
memcache and redirect the browser to my original rails app.