Are there any FOSS Python Single-Sign-on Servers?

Ben Finney bignose+hates-spam at benfinney.id.au
Tue Nov 11 20:12:29 EST 2008


Phillip B Oldham <phillip.oldham at gmail.com> writes:

> Even with using OpenID in this way, it still doesn't resolve the
> issue we have: quick user registration & sign-on. The user will need
> to register an OpenID account then register with each service/webapp
> we provide.

Why? You presumably have *existing* accounts for all these people; or
at least, some other database of people for whom you want
authentication credentials. why not cause the OpenID provider (the one
that you manage under your control, that is) to provide OpenIDs for
these existing accounts, and only those?

OpenID is a means of *authentication*, it doesn't mandate any
particular system of registration or account creation. You presumably
already have solutions for those; use them, but de-couple the
authentication process from those systems by using OpenID.

> What we're looking for is the reverse: registering our
> webapps/services with a SSO service

If you write the web application to accept OpenIDs only if they match
a specific pattern, you achieve the same effect; and you then have the
option to later choose to allow some other OpenIDs without needing to
change the authentication protocol.

> then (upon starting with the company) registering our new staff
> members with this service and specifying which webapps they have
> access to and what privileges they have with those apps.

That's quite a different thing from “single sign-on”. I recommend
you use OpenID for the purpose of authentication (proving that the
person's claim of identity is authentic), and implement whatever
system of *authorisation* (determining what the authenticated person
is authorised to do) is appropriate for each application.

You can use the associated OAuth standard protocol to transfer
information from a central provider about what authorisation
information is recorded for a person; I'm given to understand this
integrates well with OpenID.

> Please understand I have nothing against OpenID; I use it all the
> time and think its a great solution. I just don't think its a great
> solution for our particular problem.

OpenID is a solution for transporting authentication data, and
managing the data in a central location under your control. It does
well at that, because the protocol is mature (solving the transport
problem) and there are many supported free-software implementations
for providers and relying parties (allowing you to solve your specific
centralisation needs).

You later revealed that you *also* want a solution for transporting
authorisation data, and managing it in a central manner. This is a
separate issue, but OAuth is a similar solution: it is a standard
transport protocol, with many free-software implementations for both
ends of the conversation.

> Keep in mind that OpenID is user- centric.

If you mean “the user has to do the set-up work”, that's entirely
wrong. There exist *services* which *allow* people to set up a new
OpenID, but that's entirely optional. Millions of users on, e.g.
Flickr, AOL, and Yahoo, have now got OpenIDs provided without having
to do anything additional at all.

Your IT support team should be the ones setting up people's account
information, and the systems should be automatically providing OpenIDs
and OAuth profiles for any or all accounts as specified.

The user only needs to be told how to log in, once all this is set up;
and that's necessary no matter what authentication system you use.

> While I don't mind registering my openid account with the various
> sites I use, our staff members will have a nightmare spending their
> first day initially trying to understand OpenID, then registering
> with each of our services, then waiting while the support team
> review their registrations and give them relevant permissions.

Right, so you should be providing these OpenIDs and OAuth profiles as
part of whatever other data collection and account set-up needs to be
done.

-- 
 \       “If you make people think they're thinking, they'll love you; |
  `\     but if you really make them think, they'll hate you.” —Donald |
_o__)                                             Robert Perry Marquis |
Ben Finney



More information about the Python-list mailing list