Redirection-based SSO solutions?
kastork opened this issue · 4 comments
Hi,
Any ideas how this would all work with a redirection-based SSO protocol like CAS? In these systems, the login takes place on a page served by the IDP website (i.e., not your app), then your browser gets redirected back to your app with a token in the query string -- you never see the username / password, and couldn't do anything useful with it even if you did.
I am not sure, but how about this:
- you make your server respond with 401's instead of redirections, because it does not make sense to redirect a XHR request to a login page,
- once you catch the 401, open a new window with CAS login,
- in the meantime, your app can show a banner (instead of a login page),
- the banner can display a message with a button like "please click me once you are signed in", additionally you can ping your server every few seconds in a background to check if your user had done it already,
- user provides credentials in a CAS login page of a foreign service provider, once they are done, the foreign service provider redirects back to a page of your choice, so you can prepare some nice "welcome back [user name]" with a big red close button
Does it sound good? I have never done it, but why shouldn't it work this way?
Hmm, maybe...
The redirect back from the IDP contains a token that you need to process -- this is a URL you define, but it is going to be in the window that went to the external URL. (Your client app isn't present in that window, and also the redirect is real, not an XHR request). I think that return trip would have to cause the client app to load in order to feed it the info needed for the rest of your system to work as designed. Maybe we're talking about multiple endpoints -- a token vendor endpoint that does the redirection dance but doesn't contain the SPA, when satisfied it redirects your browser to the real SPA with token data in the headers for consumption by your scheme.
Why this should be problem? Once the CAS service redirects back to your page, your app will establish a SSO cookie. After it happens, you can close that window, go back to your app and it will receive this cookie on next server call. Once you get redirected from CAS back to your app (it does not matter which browser window or tab it was), you are effectively authenticated.
It seems there is no need to relaunch your application. It can continue working. After you are authenticated, you can tell it to the authService.loginConfirmed([data],[configUpdater]) and it should resend all the failed requests, so your services and controllers won't even notice the login operation happened.