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.
- 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 :(
In reply to Re: Re: "Single Sign On" perl based solutions?
by AltBlue
in thread "Single Sign On" perl based solutions?
by AltBlue
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |