First of all, please keep in mind that in this post by "Single Sign On" (SSO) I intend something like Microsoft's ".NET Passport" ("one name, one password" for every web service whatever the domainname would be) and not the meaning used by some of US universities (one name, one password for every application inside .domainname.com).

This weekend I did some online research on "single sign on" (SSO) trying to determine the pros and cons of this "technology" and eventually gathering information about such providers and even software on the market.
The main keyword in this study was (of course) "perl" :)

The "pros and cons" issue it's already a too hairy discussion so I will step over it (for now) and offer just some links for the interested ones:

First thought was to find a provider for such services and just use it (counting on the fact they offer a perl API). OK, Google eased my way and found out that every(?) such provider would be OK for me.
But as I really doubt my client would go for it (using a "remote service" for such a sensitive service) I went farther and searched for products that would be deployable on client's site. OK, I found out some, but all(?) require Java technology (at least on the server side), thing that I clearly want to avoid.

The final solution would be to implement out own home brewed SSO system... and here comes the question - a request for comments in fact from the fellow monks that maybe already did this (or are planning to do it).

Here are some points I'd like to hear more from you:

(Of course, opinions on the "pros and cons" issue - and maybe alternative systems(?!) - are welcome too :)
Thanks In Advance for all the feedback.

PS: I didn't give any commercial links here because I did not want to use this space for advertising, Google's AdSense does it very well :)

UPDATE: at arden's suggestion I minimized the usage of abbreviations/acronyms. Adding abbr (or acronym) statements for each such occurence was not possible as these tags are not allowed :(

UPDATE2: added readmore tags

--
AltBlue.

Replies are listed 'Best First'.
Re: "Single Sign On" perl based solutions?
by exussum0 (Vicar) on May 09, 2004 at 17:38 UTC
    Multiple key encyption sounds like somethign you might wiwsh to use. All sign-on session-cookie like technology you would use for a single computer/domain/area, which hopefully you encrypt, would be encrypted in a way for multiple people to decrypt with multiple private keys, one for each decryptor.

    Take this gnupg example for instance. At least then, the user nor anyone outside of the technology owners would be able to decrypt they key. Also, having different privates per monnth to make sure your key isn't cracked "someday", or stolen, would help.

    Humma la beeba la seeba la booba la
    Humma la beeba la seeba la bop
[reply]
Re: "Single Sign On" perl based solutions?
by perrin (Chancellor) on May 09, 2004 at 17:31 UTC
    What are you limitations? The problem becomes dramatically easier if you can say that every application that is going to use the system will have access to the same (private) database, or that all sites involved will be able to exchange a secret key beforehand.
[reply]

      Sharing the same database wouldn't be too good as apps should be able to be deployed on each client's site (multinational, offices in too many countries etc).

      On the other hand, sharing secret keys is obvious to be expected in any scenario in order for each "service provider" to be able to communicate (securely) with the "login server".

      I don't expect in fact too much trouble in implementing the inter-"service" communication, my concerns are directed more towards client-service communication (authentication/authorization in fact): the only bit of information a browser could keep is cookies which are limited by domain.

      Let's play with an example in fact:
      Login server:
      access-foo.com
      Intranet servers (only authorized users are allowed):
      us-foo.com
      eu-foo.com
      jp-foo.com
      ...
      "Public" servers (which have in fact content different by access level - including "usual guest" visitor):
      foo.com
      ...


      - Each server should have a secure way to determine (by quering access-foo) if the user is still authorized to access a resource.
      - Clients (browsers) should be able to login one-time-only (the first time they access one of these *-foo services) and then to be transparently authorized to access (at the proper level ofc) any other resource on any other *-foo server :)
      - Logout (session expiration) should be done globally (again, in a tranparent mode for the user).
      - Access service should be easy to be replaced with a "local" service whenever needed (should be easy to do if data isolation/encapsulation if well established from start: "global attributes" should stay on access-foo and only those).

      Authentication is clear how to do it, access-foo will handle this, but how/where could the authorization be done? I guess it could get very sluggish to authorize with the access-foo at every "page", but on the other hand, if done locally, people could get "stalled" access (e.g.: the account is already disabled on access-foo, but it's still valid on *-foo as "session has not yet expired", etc)

      Even more, what to do with those "access level based" services? It would surely get very sluggish (and bad user experience too) to redirect client to the access-foo at each request in order to refresh it's authorization. How could this be handled? Again, as transparent as possible.

      First thought was to replace redirects by requesting "authorization refreshes" through those "secure lines" between services and access-foo, but I think this is just as feeble as the other approach (more or less of course).

      Another idea would be to make access-foo to push those "authorization refreshes" to each *-foo server each time an event occurs (user login/logout, expiration etc) ... This seems more interesting, but is it good enough? Why burden each *-foo service with those updates if they do not need it?

      ...

      UPDATE: at arden's suggestion I minimized the usage of abbreviations/acronyms. Adding abbr (or acronym) statements for each such occurence was not possible as these tags are not allowed :(

      --
      AltBlue.
[reply]
        the only bit of information a browser could keep is cookies which are limited by domain.

        A browser can also send get/post parameters, which is the usual way to keep session when cookies are disabled. Thus, if the service receives a token as a means for user authentication, each time it generates a link to another service it should add a token to it. For instance, http://other-foo.com would become http://other-foo.com?token=xxx.

        On the other hand, sharing secret keys is obvious to be expected in any scenario in order for each "service provider" to be able to communicate (securely) with the "login server".

        I would rather use a public key crypto scheme and share public keys rather than secret keys. This allows confidentiality during information exchange without requiring a previous confidential channel for key exchange and lets you keep each private key in a single location, thus reducing leakage risk.

        if done locally, people could get "stalled" access
        Would you really need real-time authorization changes? I would let services poll the authorization server every now and then (say half an hour) to check if any authorization has changed and in that case invalidate all sessions for no-more authorized clients. This would be totally transparent to the user and would not require much network traffic or impose delays in navigation, while still keep the system quickly responsive to authorization changes.

        Cheers

        Antonio Bellezza


        The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket
[reply]
Re: "Single Sign On" perl based solutions?
by dragonchild (Archbishop) on May 10, 2004 at 12:21 UTC
[reply]

Back to Meditations