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

[Phillip B Oldham]

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

We're looking to centralise the sign-on for our numerous "internal"
webapps (across multiple servers, languages, and domains) to speed
user management and application development.

I've searched around but can only seem to find OpenID servers, which
will probably be too "open" for our needs. Coding one up would
possibly take more time than we have, and we'd prefer something
maintained externally to cut dev costs.

[paul]

Phillip B Oldham schrieb:

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

[snip]

I've searched around but can only seem to find OpenID servers, which
will probably be too "open" for our needs.

So if it is not OpenID, which protocol are you going to implement?

cheers
Paul

[Phillip B Oldham]

On Nov 11, 9:24*pm, paul <[e-mail]:

Phillip B Oldham schrieb:Are there any FOSS Python Single-Sign-on Servers?

[snip]

I've searched around but can only seem to find OpenID servers, which
will probably be too "open" for our needs.

So if it is not OpenID, which protocol are you going to implement?

In theory, we could use an OpenID server: our staff could register
with something like MyOpenID, register with each of our individual
webapps, and then gain access with a single sign-on. However, its not
really getting round the problem we have: we need to give our staff
access to all of our apps in one go, give them one place to sign on,
and have the ability to disable their account at short notice. Doing
this with openid would mean we have *no* access to the user account
and therefore would still have the overhead of having to disable
accounts with each webapp we provide. It also opens-up a security
threat in that anyone could register to our "internal" apps with an
OpenID account. Which is bad.

Essentially, we need a SSO server with which we would register our
*webapps* and then create user account, specifying which webapps that
user has access to, and at what level. Essentially something like
OpenSSO but python-based.

[Ben Finney]

Phillip B Oldham <ph************@gmail.comwrites:

I've searched around but can only seem to find OpenID servers, which
will probably be too "open" for our needs.

Huh? I'm sure you use HTTP for transferring requests and responses,
too, and that protocol is at least as as open. What does the openness
of the protocol have to do with who can access it?

Please, if you're going to be coding new systems, use established,
standard, open protocols with actively maintained implementations. For
single sign-on. OpenID is the one to choose.

--
\ “I stayed up all night playing poker with tarot cards. I got a |
`\ full house and four people died.� —Steven Wright |
_o__) |
Ben Finney

[Phillip B Oldham]

On Nov 11, 11:00*pm, Ben Finney <[e-mail]>
wrote:

Phillip B Oldham <[e-mail]:

I've searched around but can only seem to find OpenID servers, which
will probably be too "open" for our needs.

Please, if you're going to be coding new systems, use established,
standard, open protocols with actively maintained implementations. For
single sign-on. OpenID is the one to choose.

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, we simply
want to centralise registration and sign-on for our employees.

[Ben Finney]

Phillip B Oldham <ph************@gmail.comwrites:

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.

This could be done by, as one possible example, only accepting OpenIDs
of the form ‘http://example.com/openid/username’ (or whatever URL path
you deem useful), and ensuring that you control the OpenID provider
that serves those OpenIDs.

--
\ “He who allows oppression, shares the crime.� —Erasmus Darwin, |
`\ grandfather of Charles Darwin |
_o__) |
Ben Finney

[Phillip B Oldham]

On Nov 11, 11:48*pm, Ben Finney <[e-mail]>
wrote:

Phillip B Oldham <[e-mail]:

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.

[Steve Holden]

Phillip B Oldham wrote:

On Nov 11, 9:24 pm, paul <[e-mail]:

>Phillip B Oldham schrieb:Are there any FOSS Python Single-Sign-on Servers?

[snip]

>>I've searched around but can only seem to find OpenID servers, which
will probably be too "open" for our needs.

So if it is not OpenID, which protocol are you going to implement?

In theory, we could use an OpenID server: our staff could register
with something like MyOpenID, register with each of our individual
webapps, and then gain access with a single sign-on. However, its not
really getting round the problem we have: we need to give our staff
access to all of our apps in one go, give them one place to sign on,
and have the ability to disable their account at short notice. Doing
this with openid would mean we have *no* access to the user account
and therefore would still have the overhead of having to disable
accounts with each webapp we provide. It also opens-up a security
threat in that anyone could register to our "internal" apps with an
OpenID account. Which is bad.

Essentially, we need a SSO server with which we would register our
*webapps* and then create user account, specifying which webapps that
user has access to, and at what level. Essentially something like
OpenSSO but python-based.

Why not just implement a private OpenID server and only accept
identities from that domain?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Phillip B Oldham]

On Nov 12, 1:12*am, Ben Finney <[e-mail]>
wrote:

Phillip B Oldham <[e-mail]:
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.

Ah, I see!

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.

I think I have some misconceptions about OpenID then.

So, would it be possible to use the user's email address as their
OpenID username/token?

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).

It's all starting to "click" now. Thanks for being persistent! ;)

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.

OAuth was also something I came across, but discounted as possibly
being too "open".

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.
[snip]
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.

Sounds just like what I'm looking for.

So... are there any good OpenID/OAuth servers written in python?

[Ben Finney]

Phillip B Oldham <ph************@gmail.comwrites:

So... are there any good OpenID/OAuth servers written in python?

Rather than continue the discussion in this thread, I'll point you to
the starting point for further information at the OpenID site
<URL:http://openid.net/developers/>.

Good hunting!

--
\ “I can picture in my mind a world without war, a world without |
`\ hate. And I can picture us attacking that world, because they'd |
_o__) never expect it.� —Jack Handey |
Ben Finney