in reply to Re: "Single Sign On" perl based solutions?
in thread "Single Sign On" perl based solutions?

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.
  • Comment on Re: Re: "Single Sign On" perl based solutions?

Replies are listed 'Best First'.
Re: Re: Re: "Single Sign On" perl based solutions?
by abell (Chaplain) on May 10, 2004 at 10:08 UTC
    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]

In Section Meditations