Warning: This article contains more than your recommended daily allowance of vitamin Geek. Non-geeks should look away now and check out some of our other articles.About Shibboleth
Shibboleth (http://shibboleth.internet2.edu), according to it's website:
is standards-based, open source middleware software which provides Web Single SignOn (SSO) across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.
That, from the point of view of a developer needing to integrate with Shibboleth isn't much help. Having read through a great deal of documentation on the website I was still non-the-wiser. Enlightenment came after I spoke to the very helpful Fiona Culloch who explained it all.
In a Nutshell
So here, for any developers trying to get their head around how to integrate Shibboleth into an existing app, is the lowdown in 60 seconds:
- Your application does not communicate with Shibboleth directly. The 'magic' happens before any of your code is run.
- When a request for a page is made, Shibboleth checks to see if the page requires authentication. If it does, Shibboleth redirects the user to an authentication page where they enter their credentials (usually their username / password).
- Once authenticated or if the page doesn't require authentication, normal (web)service resumes. Shibboleth inserts some data into the web server environment variables and then passes control back to your page. You can read this data in your application and use to identify the user.
- Shibboleth remembers the user has authenticated on each subsequent page request and continues to update the environment variables until the user ends the session.
- If they failed to authenticate, protected pages are never reached and the environment variables are never set.
Simple eh? And secure too. At no point in the process is anything that could be used to identify your user made visible to any potential snoopers.
Who Are you?
So, how do you know WHO your user is and and WHAT they are allowed to do in your application?
One of the environment variables Shibboleth sets is the 'targeted id'. This ID is unique to the user but doesn't contain any identifying information.
You can arrange with Shibboleth to insert additional information (such as their group, their email address etc.) but for the majority of developers, your application will already be storing this kind of information.
Integrating With Your System
I'm assuming you already have some sort of Access Control system in place in your application. In this case, you would store the targeted id in your user table along side all the usual stuff you store about your uses and use the one supplied in the environment variable to lookup their details in your system.
Practical Examples
Here's a few examples of the most common authentication requirements. These examples assumes you are using your own user / groups / roles / permissions code. We are using Shibboleth purely to handle the authentication.
Page 1:
Synopsis:
- Viewable by anyone.
- For anyone not signed in, display a link to the login page (4).
- For authenticated users, add a link to page 2
- For authenticated users in the admin group, add a link to page 3
Pseudocode:
display the page
if shibboleth environment variable is empty {
display a link to the sign in page (4)
}
else {
display the link to page 2
using the environment variable, lookup the user's details
if the user's group is "admin" {
display the link to page 3
}
}
Page 2:
Synopsis:
- Only visible to authenticated users, irrespective of which group they are in
Pseudocode:
if the shibboleth environment variable is empty {
access denied
}
else {
display the page
}
Page 3:
Synopsis:
- Only visible to authenticated users in the admin group
Pseudocode:
if the shibboleth environment variable is empty {
access denied
}
else {
using the environment variable, lookup the user's details
if the user's group isn't "admin" {
access denied
}
else {
display the page
}
}
Page 4:
Synopsis:
- Sign in page
Pseudocode:
redirect the user to page 1
Hang on a minute, what's happing on page 4?
Firstly, you must instruct the Shibboleth module in advance that page 4 requires authentication. This is the only page in this example that Shibboleth is 'protecting'. This is usually a job for the Shibboleth System Administrator and out of scope for this article.
When the user follows the sign in link, shibboleth sees that the sign in page requires authentication and redirects the user to the shibboleth authentication page.
Once the user has authenticated, Shibboleth sets its environment variables and redirects them back to our sign in page. The sign in page redirects them back to page 1 as Shibboleth continues to update the environment variables for each subsequent page request.
If they fail to authenticate, the code never runs and the environment variables are never set
Questions and Comments?
Do you have any tips or tricks for working with Shibboleth? I'd love to hear them!
2 comments:
Just a note that you may need to use Shibboleth's "lazy sessions" feature, otherwise the default is to force authentication automatically the first time the user hits a any protected page.
Thanks for the feedback Finona! I'll be revisiting this article in a week or so's time to clear up a few bits and pieces.
Post a Comment