3 ms·

Hopefully not. They should just use CAS.

by SDGT 13y ago

e12e 13y ago
I agree with you both, at the same time not everything using a session/token auth/authz combination needs to be "kereberos". While one might argue if it's good or bad, we've long let the web server be the authentication/authorization boundary -- and there's not really anything wrong with formalizing the architecture into a auth.example.com and a service[1-through-n].example.com. Let sessionN.example.com check for a valid sessionN cookie, if it's missing, let SessioN.x.c set a temp cookie, pushing a token also to auth.example.com, then -- the client that's missing a valid session for serivceN, is redirected to auth.example.com with a ?token=<encrypted>. Auth does the authentication, and bounce back to serviceN. [edit: Hm, I'm completely missing the SSO bit here, actually -- at the minimum there's a redirect bounce for every new service N+1 the client access after obtaining a valid session for auth.x.c. That would probably be a problem for AJAX? Maybe it's possible to wrap with javascript in a sane way] Client has a session (flagged not authenticated, not authorized) for ServiceN. ServiceN asks auth for the status of the session-token, gets a valid (optionally along with authorization data -- depends what "authenticated" means) -- assuming a valid reply, ServiceN sets up a "proper" session (eg: php session id, whatever framework ServiceN uses). Basically Single-sing-in -- without single-sign-out (unless ServiceN can/does sign client out via auth.x.c on sign-out from ServiceN). Yes, this is basically CAS/Shibboleth/etc -- but for medium sized architectures it might actually be simpler. All interaction(s) assume trusted communication paths (ssl for client-server/service -- vpn/ssl/internal for service-service). The other way (less web centric?) is to simply have Service1-N lookup via LDAP/AD/RADIUS towards some central internal user database).

3 ms·

Hopefully not. They should just use CAS.

by SDGT 13y ago

Hopefully not. They should just use CAS.

e12e 13y ago
I agree with you both, at the same time not everything using a session/token auth/authz combination needs to be "kereberos". While one might argue if it's good or bad, we've long let the web server be the authentication/authorization boundary -- and there's not really anything wrong with formalizing the architecture into a auth.example.com and a service[1-through-n].example.com. Let sessionN.example.com check for a valid sessionN cookie, if it's missing, let SessioN.x.c set a temp cookie, pushing a token also to auth.example.com, then -- the client that's missing a valid session for serivceN, is redirected to auth.example.com with a ?token=<encrypted>. Auth does the authentication, and bounce back to serviceN. [edit: Hm, I'm completely missing the SSO bit here, actually -- at the minimum there's a redirect bounce for every new service N+1 the client access after obtaining a valid session for auth.x.c. That would probably be a problem for AJAX? Maybe it's possible to wrap with javascript in a sane way] Client has a session (flagged not authenticated, not authorized) for ServiceN. ServiceN asks auth for the status of the session-token, gets a valid (optionally along with authorization data -- depends what "authenticated" means) -- assuming a valid reply, ServiceN sets up a "proper" session (eg: php session id, whatever framework ServiceN uses). Basically Single-sing-in -- without single-sign-out (unless ServiceN can/does sign client out via auth.x.c on sign-out from ServiceN). Yes, this is basically CAS/Shibboleth/etc -- but for medium sized architectures it might actually be simpler. All interaction(s) assume trusted communication paths (ssl for client-server/service -- vpn/ssl/internal for service-service). The other way (less web centric?) is to simply have Service1-N lookup via LDAP/AD/RADIUS towards some central internal user database).