shibboleth (SAML) support

[Geert]

Hi all,

As I announced in another post, at SURFnet we have created an additional way of authorizing users in Edukapp: by using Shibboleth as a SAML SP in an Apache httpd module.

This functions as follows:

* all requests to Edukapp are processed by a servlet filter

* this filter requires a user-identifying request header being present

* - if not present, redirect to Shibboleth to let the user authenticate

* - if present, authorize this user against the local (edukapp) user store, optionally applying roles etc.

For now, these limitations apply:

- Useraccounts have to be present in Edukapp before authentication (provisioned upfront), they are not created dynamically

- Users do not get any roles assigned; it seems there is no real role based authorization set up, only a roles table which is empty.

- All requests are checked for authentication right now. There is no distinction between public pages and protected pages.

Refer to the patch attached. This configures a (disabled) servlet filter along with a Shiro Security Realm that together do the work.

The patch can be applied without affecting the current authorization setup.

It also contains the unit tests for the new classes.

To test this locally (I presume one does not have a Shibboleth instance running locally):

* enable the shibbolethFilter in web.xml (it is commented out by default, refer to the prepended security warning in web.xml)

* Visit the application (http://localhost:8080)

* see that you get redirected to http://localhost:8080/Shibboleth.sso/Login.

(When running Shibboleth, this request triggers the Shibboleth module to start the authentication (probably redirecting to a WAYF etc.

For now, presume that Shibboleth completes authentication and sets a REMOTE_USER-header on the request)

* Now, configure your browser to send a custom header for every request (using an addon like 'Modify Headers' [1] for Firefox, or 'Header Hacker' [2] for Chrome): let it send:

REMOTE_USER: geert

(substitute geert for a username that is present in the useraccounts table)

* Visit http://localhost:8080/

* See that 'geert' is logged in now.

So this is the flow that normally happens when having Shibboleth running. It fakes the parts that Shibboleth typically performs:

- processing the /Shibboleth.sso/Login request

- setting a REMOTE_USER header on the request when returning to the application after having authenticated the user.

Let me know what you think of this.

Kind regards,

Geert

[1] https://addons.mozilla.org/en-US/firefox/addon/modify-headers/

[2] https://chrome.google.com/webstore/detail/phnffahgegfkcobeaapbenpmdnkifigc

[Scott Wilson]

On 20 Jul 2012, at 10:11, Geert wrote:

Hi all,

As I announced in another post, at SURFnet we have created an additional way of authorizing users in Edukapp: by using Shibboleth as a SAML SP in an Apache httpd module.

This functions as follows:

* all requests to Edukapp are processed by a servlet filter

* this filter requires a user-identifying request header being present

* - if not present, redirect to Shibboleth to let the user authenticate

* - if present, authorize this user against the local (edukapp) user store, optionally applying roles etc.

For now, these limitations apply:

- Useraccounts have to be present in Edukapp before authentication (provisioned upfront), they are not created dynamically

- Users do not get any roles assigned; it seems there is no real role based authorization set up, only a roles table which is empty.

Yes, thats there for future use when we add users with rights to do things like moderate posts and review uploaded widgets - currently there is just a generic set of permissions for normal users.

- All requests are checked for authentication right now. There is no distinction between public pages and protected pages.

Refer to the patch attached. This configures a (disabled) servlet filter along with a Shiro Security Realm that together do the work.

The patch can be applied without affecting the current authorization setup.

It also contains the unit tests for the new classes.

To test this locally (I presume one does not have a Shibboleth instance running locally):

* enable the shibbolethFilter in web.xml (it is commented out by default, refer to the prepended security warning in web.xml)

* Visit the application (http://localhost:8080)

* see that you get redirected to http://localhost:8080/Shibboleth.sso/Login.

(When running Shibboleth, this request triggers the Shibboleth module to start the authentication (probably redirecting to a WAYF etc.

For now, presume that Shibboleth completes authentication and sets a REMOTE_USER-header on the request)

* Now, configure your browser to send a custom header for every request (using an addon like 'Modify Headers' [1] for Firefox, or 'Header Hacker' [2] for Chrome): let it send:

REMOTE_USER: geert

(substitute geert for a username that is present in the useraccounts table)

* Visit http://localhost:8080/

* See that 'geert' is logged in now.

So this is the flow that normally happens when having Shibboleth running. It fakes the parts that Shibboleth typically performs:

- processing the /Shibboleth.sso/Login request

- setting a REMOTE_USER header on the request when returning to the application after having authenticated the user.

Let me know what you think of this.

This is great - I got it working (you also have to add shibbolethRealm = uk.ac.edukapp.shibboleth.ShibbolethRealm to shiro.ini) - if we also add in automatic provisioning, and allow switching between shib and "normal" logins,  this will be a really useful feature. Thanks!

I've committed the patch with a couple of modifications (the comments in shiro.ini, removed @Override annotations where Eclipse was complaining)

Kind regards,

Geert

[1] https://addons.mozilla.org/en-US/firefox/addon/modify-headers/

[2] https://chrome.google.com/webstore/detail/phnffahgegfkcobeaapbenpmdnkifigc

<Support_Shibboleth_authentication.patch>

[Geert van der Ploeg]

This is great - I got it working (you also have to add shibbolethRealm = uk.ac.edukapp.shibboleth.ShibbolethRealm to shiro.ini) - if we also add in automatic provisioning, and allow switching between shib and "normal" logins,  this will be a really useful feature. Thanks!

I've committed the patch with a couple of modifications (the comments in shiro.ini, removed @Override annotations where Eclipse was complaining)

Thanks.

Locally I added this realm definition in shiro.ini but apparently I reverted it...

I think the realm could be configured by default without any harm. As long as there is no servlet-filter that actually creates a ShibbolethToken and thereby uses the realm...

But that's a minor issue. Let's improve other things first :-)

Regards,

Geert