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

Discussion in 'Python' started by Phillip B Oldham, Nov 11, 2008.

  1. 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.
    Phillip B Oldham, Nov 11, 2008
    #1
    1. Advertising

  2. Phillip B Oldham

    paul Guest

    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
    paul, Nov 11, 2008
    #2
    1. Advertising

  3. On Nov 11, 9:24 pm, paul <> wrote:
    > 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.
    Phillip B Oldham, Nov 11, 2008
    #3
  4. On Nov 11, 11:00 pm, Ben Finney <>
    wrote:
    > Phillip B Oldham <> writes:
    >
    > > 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.
    Phillip B Oldham, Nov 11, 2008
    #4
  5. On Nov 11, 11:48 pm, Ben Finney <>
    wrote:
    > Phillip B Oldham <> 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.
    Phillip B Oldham, Nov 12, 2008
    #5
  6. Phillip B Oldham

    Steve Holden Guest

    Phillip B Oldham wrote:
    > On Nov 11, 9:24 pm, paul <> wrote:
    >> 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 +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
    Steve Holden, Nov 12, 2008
    #6
  7. On Nov 12, 1:12 am, Ben Finney <>
    wrote:
    > Phillip B Oldham <> writes:
    > 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?
    Phillip B Oldham, Nov 12, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Cowboy \(Gregory A. Beamer\)

    Single Sign on for web apps on same box

    Cowboy \(Gregory A. Beamer\), Nov 5, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    378
    Cowboy \(Gregory A. Beamer\)
    Nov 5, 2003
  2. Jimmy
    Replies:
    1
    Views:
    930
    Cowboy \(Gregory A. Beamer\)
    Nov 21, 2006
  3. Phillip B Oldham

    FOSS projects exhibiting clean/good OOP?

    Phillip B Oldham, Jul 9, 2008, in forum: Python
    Replies:
    9
    Views:
    332
  4. John Sheppard

    Are there any issues with ASP and proxy servers?

    John Sheppard, Nov 30, 2004, in forum: ASP General
    Replies:
    6
    Views:
    137
    John Sheppard
    Dec 2, 2004
  5. Jimmy
    Replies:
    3
    Views:
    2,393
    shimmyshack
    Nov 20, 2006
Loading...

Share This Page