> 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
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
