Shibboleth

[Gilles Badouet]

Hi all,

Thanks for your assistance.

Peter, your recent description is really helpful, I am getting used to the whole concept quicker by reading you wordings and hope 5 months will be sufficiant to complete that project. It looks like I will have a lot of things to do. However, I think I could with your help and the help of all the forum because I am really committed to that project.

Obviously I am not goinna modify Shibboleth code as I am far to be a professional programmer.


1- Do you think the final title of the project as I modified is suitable regarding the deliverables and objectives? If not please I would like your suggestions. I am asking because I must submit to my University the project brief report with the right title and the project details. 

2-Once all will be clear in my head, I will further learning about SAML,/XML, stressing on the SSO mechanism.
I will then look in depth at Shibboleth SP, IdP. 

3- Accroding to what you said, I wont need to install other Shibboleth products ( Embedded& centralised Discovery servicice, meta data aggregator...). I should most stress on SP and IdP, am I right?

4- Please what webserver (Apache or Microsoft IIS Server...) will you advice me for more compatibility and what version  ?


Kind regards



Gilles Rubens Badouet
Student ID: 3940347
Faculty of Engineering and Computng
MSc Network Computing Course
Mobile: 07424486426

________________________________________
From: Peter Schober [peter.schober at univie.ac.at]
Sent: 07 March 2013 09:07
To: Gilles Badouet
Subject: Re: Shibboleth

Please keep replies to the list.
I'll Cc: any further replies there myself.

* Gilles Badouet <badouetg at uni.coventry.ac.uk> [2013-03-06 23:48]:
> I would highly like you to have a look on that deliverables and help
> me to set a final suitable title for the project if you dont
> mind.

The title is mostly irrelevant, I suppose.

> The company has applications which need to authenticate against Shibboleth when someone logs in.
> Objectives:
>
>   1.  Review Shibboleth as a single sign-on mechanism
>   2.  Download Shibboleth and document its architecture
>   3.  Produce small application to test out single sign-on in java.
>   4.  Produce small application to test out single sign-on in C#.Net.
>   5.  Install our library solution which is an ASP.Net solution and implement Shibboleth single sign-on if you have time.
>   6.  Review alternative technologies and ways to extend this for the future

That suffers from a slight confusion as "Shibboleth" is not one
thing. It's a project that produces several software components which
support several protocols. Guessing the intention, it's probably safe
to replace "Shibboleth" with "SAML 2.0 WebSSO Profile" in all uses,
except where software installation and configuration is concerned.

Think about this like the web: We have standard protocols (HTTP),
software implementations (e.g. Apache httpd web server, Mozilla
Firefox web browser, etc.), consortia (the Apache Foundation), etc.

Shibboleth is a Consortium http://shibboleth.net/ a bit like the
Apache Foundation and produces software that implements (among other
things) much of the available SAML specs (or Profiles).
(You should read up on the SAML spec ad what it is you implement.)

So 1. means reading up on SAML (the spec has technical and nontechical
introduction documents) and probably all of
https://wiki.shibboleth.net/confluence/display/SHIB2/UnderstandingShibboleth
(several times, as it will take some time to grasp the more advanced
topics). The Shib wiki has lots of conceptual material, use it.

2. would probably mean to install a Shib SP (the thing that protects
resources on a webserver) and the Shib IDP (the thing that handles
authentication and provides Web Single Sign-On to all SPs its
connected to). Both parts can take a long time to wrap your head
around, so for the sake of limiting the scope of your work I'd say
stick to the SP and use an already existing IDP (e.g. testshib or from
your own University). Going into the details of an IdP create no value
for the client as they're all about their resources (so SP usage).

3. and 4. are then reduced to a properly configured webserver
(probably MS-IIS, if you have to support C# ?) configured with the
Shibboleth SP. The application code can be trivial and examples are in
the Shib wiki:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess#NativeSPAttributeAccess-Tool-SpecificExamples
Shibboleth has *no* API for programming languages, it runs in the
webserver and so is tools-agnostic. From your program to interface to
"it" by reading HTTP request headers or environment variables.

Which is why I said there is nothing to programm for Shibboleth
(unless you wanted to change the software itself, which is written in
object oriented C++). So the task may sound like it's about
programming, but to do what they ask for it's all about the details of
configuring the Shibboleth SP software. It can do all you need (and
much more) but that makes it rather complicated as a whole.

How to do 5. is described in the wiki:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication
so that's a classical case of trying to make an application available
via SAML2 WebSSO. Whether that's possible at all or how difficult or
easy this is depends completely on the application (the "library
solution"). It the "solution" allows for externalizing some of its
authentication and authorization stuf, it will be easy. Most insist on
doing everything themselfs (hard-coded) and it will be impossibke
without code changes to the applicatoon software itself.
So that may very well be too hard and too much work.
(Also doing such an integration *properly*, without introducing too
many security holes, and allowing for easy logout later on,
etc. requires quite a bit of understanding of the whole Shibboleth
thing.)

6. would probably mean to look at other protocols than SAML2 (the
obvious upcoming contender is "OpenID COnnect") and/or other
SAML2-implementations, as are available from commercial vendors -- and
most of them are crap compared to Shibboleth -- or available
open-source, like SimpleSAMLphp, which by itself can only be used for
PHP-applications, so won't help with Java or C#. For those two cases
there are OIOSAML.Java and OIOSAML.NET, which are SAML-implementations
based on APIs and tooltkits. I.e., not the Shibboleth way of
integrating with the webserver (once) and use all languages and APIs,
but code your application to the API of the OIOSAML toolkit. That
impies you can write or change the application code yourself (which
often is neither possible nor desireable) and that you will have to
maintain that code over the life of the application (with updates, API
changes, etc.). Also none of those toolkits offer the rich
functionality of the Shibboleth SP, so there are many reasons not to
use such a thing in production.
Also, using an OIOSAML (or other, like Spring Security SAML extension)
tookit is not "implementing Shibboleth", it's replacing the Shibboleth
implementation with a different implementation. But if you'd rather
learn one of those APIs and try to actually implement your own SAML SP
based on that (which will be problematic throw-away code and no use to
anyone, except as  a lerning experience for you) you could interpret
the requirement that way and use OIOSAML instead of Shibboleth.
(That is, of you'd rather program than configure preexisting software.)

>  Major deliverables:
>
>   1.  Reviews of existing approaches and alternative approaches

Could mean Intra- vs. Inter-Institutional SSO systems (e.g. Kerberos
is intra-institutional and also for non-web stuff; SAML2 is
inter-institutional but with current profiles mostly for web).
Could also mean what I wrote above about SAML implementations based on
integration via APIs (SimpleSAMLphp, OIOSAML, etc.) or based on the
avoidance of APIs for integration (Shibboleth).

>   2.  Review of deployment  strategy

Seems to tie in to many things I've already said. E.g. with API-level
integration there's a high cost involved in the long run (to maintain
the code). HTTP request headers on the other hand don't change when
any software component changes.

>   3.  System Design Specification

No idea. I'm not an Engineering Student ;)
But there's probably material available in the wiki, or you can always
ask on the user or developer mailing list.

>   4.  Deployment in a working prototype

Just the SP, as I suggested above.

>   5.  Entity relationship model and SQL script for demonstration if required

ER is a bit antiquated, I think, since we have the relational model.
(Any entity can also be modelled as a relation between other things, so
what's the difference between entities and relations? But I am not a
Computer Science student either :)

You've read your Codd, right?

>   6.  Test data and test schedule

Hm. What to test? Your trivial code showing that someone is
succesfully logged in to a Shibboleth protected webserver?

>   7.  Short ‘Getting Started’ Guide

That (short!) sounds like fun :)
I've written a deployment guide for a Shib-integrated service we
shipped as a VMware image to the customer. But it's in German.

>   8.  Suggestions as to where to go from here

Could mean anything. Adding more features to the integration, adding
other protocols, moving it into a cloud-based data center, adding
high-availability, etc.

All the best,
-peter