4 ms·

"The idea is that you'll have an authentication server (or it could be part of your core API) which is responsible for giving users their token. Once a user has

"The idea is that you'll have an authentication server (or it could be part of your core API) which is responsible for giving users their token. Once a user has a token, they can hit any of the applications, and the application can very easily check the validity of the token before deciding what to do with the request." Are people really trying to reinvent Kerberos just so they can use the familiar JSON?

lstamour 13y ago
Well, yeah, since Kerberos stubbornly hasn't re-invented itself to use HTTP over port 80. Another option you could have said was client-side SSL certificates, though they're simply not portable enough for most uses. Finally, why bother implementing a sign-in service at all? You could follow the AccountChooser model and simply allow users to sign in using their own existing email address. Details at the recently redesigned http://www.accountchooser.net/developers http://www.accountchooser.net/developers ... though to support email providers you don't already have IdP relationships for, I guess that means letting them sign up for a password via email validation after all. Well, if nothing else, I think it points out that Kerberos was designed for one institution, but today we often want multiple identities on the web, and that better fits a decentralized, browser-stored model of "SSO" or login, e.g. AccountChooser screens.
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).

lstamour 13y ago

Well, yeah, since Kerberos stubbornly hasn't re-invented itself to use HTTP over port 80. Another option you could have said was client-side SSL certificates, though they're simply not portable enough for most uses. Finally, why bother implementing a sign-in service at all? You could follow the AccountChooser model and simply allow users to sign in using their own existing email address. Details at the recently redesigned http://www.accountchooser.net/developers http://www.accountchooser.net/developers ... though to support email providers you don't already have IdP relationships for, I guess that means letting them sign up for a password via email validation after all. Well, if nothing else, I think it points out that Kerberos was designed for one institution, but today we often want multiple identities on the web, and that better fits a decentralized, browser-stored model of "SSO" or login, e.g. AccountChooser screens.

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).