[cryptography] Request for Reviewers of WebSSO design (was: Fwd: Request for Reviewers)

=JeffH Jeff.Hodges at KingsMountain.com
Mon Dec 2 12:56:08 EST 2013


 > I've been asked to put together a design for a single sign on system
 > for the KDE project (www.kde.org) to use to provide a single login
 > server for all the various websites the project uses. If anyone has
 > time to take a look and see if I've left any design flaws then I'd
 > appreciate the feedback. The design is outlined at
 > http://xmelegance.org/devel/identitiy_kde_org/DESIGN and there's a
 > strawman python implementation (using pycrypto) at
 > http://xmelegance.org/devel/identitiy_kde_org/identity_kde_sso-0.4.tar.gz
 > that shows how the clients and server would work. I'll attach the
 > design document to this email in case that makes it easier for people.
 > Any feedback is appreciated.


Well, I don't have much feedback on your design (other than terminology) 
because the short answer is that this functionality -- Web single sign-on -- 
has been invented and re-invented a vast multitude of times, and there are 
various open protocols and open implementations thereof deployed all over 
the proverbial place.

So I'd suggest researching these existing ones and figuring out which of 
them might meet your needs and doing some testing/piloting and go from there.

the hard part is the "researching them" bit because you need to understand 
your needs -- and SSO is one of those 
seemingly-simple-but-has-subtle-complexities things [1].

In terms of your terminology, what you're calling a "client" is often termed 
a "service provider (SP)" and what you're calling a "server" is often called 
an "identity provider (IDP)".  Some protocol communities have their own 
similar terms (see: openid) for these.

For a (decent, but incomplete it seems) list of implementations of WebSSO, 
there's this..

   https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations

..but it doesn't (e.g.) include..

   http://simplesamlphp.org/


The latter implementation brings up on of those subtle-but-important points: 
protocol diversity.  Since websso has been multiply re-invented there's a 
plethora of protocols that all do pretty much the same thing. So clueful IDP 
implementors make their IDP impl multi-protocol, such as simplesamlphp's.

One's IDP impl can often be impl'd in just one language, since you're 
probably going to just run one.

It's SP impls (that live out on the various web sites that need SSO 
services) where one needs impl diversity -- but if you choose one or a small 
number of widely implemented protocols to fully support on the IDP (e.g. 
SAML, OpenID Connect, OAuth, OpenID), then there will be a plethora of SP 
implementations in various languages available, and likely a range of 
website platform plugins (like for wordpress, drupal, etc) that you can 
leverage.

Another consideration would be to see about whether the linux distro 
community wishes to build their own "federation" in which case you all would 
want/need to talk to each other and make some decisions about protocols and 
impls to all use.  Examples of such federations abound in commercial 
(google's, yahoo's, twitter's, canonical's, etc), higherEd/research 
(incommon.org (perhaps the largest federation on the Internet by various 
definitions (and is based on the Shibboleth impl [2] ))), etc.

For considerations as to why WebSSO federations in some settings have been 
more successful than others, there's this interesting paper that's worth 
reading...

[1] Economic tussles in federated identity management
Susan Landau, Tyler Moore
First Monday, 	Volume 17, Number 10 - 1 October 2012
http://firstmonday.org/ojs/index.php/fm/article/view/4254/3340

[2] https://en.wikipedia.org/wiki/Shibboleth_%28Internet2%29


HTH,

=JeffH







More information about the cryptography mailing list