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

[Phillip B Oldham]

On Nov 11, 11:48 pm, Ben Finney <bignose+hates-s... at benfinney.id.au>
wrote:
> Phillip B Oldham <phillip.old... at gmail.com> writes:
>
> > I think maybe there's some misunderstanding. The protocol isn't the
> > issue; I'm happy to use whatever (HTTP, LDAP, SOAP, XMPP, etc). The
> > issue is that OpenID, by its name, is open. We don't want to allow
> > anyone with an openid account to register with our webapps
>
> Then don't do that. The OpenID protocol says nothing whatsoever about
> *which* OpenIDs your service will accept.
>
> > we simply want to centralise registration and sign-on for our
> > employees.
>
> Then you should reject any attempt to authenticate with an OpenID that
> you don't accept.

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. What we're looking for is the reverse: registering our
webapps/services with a SSO service 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.

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. Keep in mind that OpenID is user-
centric. 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.

Since the support team will have to do this, along-side setting up
email accounts, it makes sense for them to have one interface to grant
access & permissions to the various webapps and for our staff to have
one place to sign-on. Since each staff-member already has a unique
email address it again makes sense to use this rather than an openid-
url which could be confusing.