Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redirection-based SSO solutions? #65

Open
kastork opened this issue Apr 15, 2014 · 4 comments
Open

Redirection-based SSO solutions? #65

kastork opened this issue Apr 15, 2014 · 4 comments

Comments

@kastork
Copy link

kastork commented Apr 15, 2014

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.

@witoldsz
Copy link
Owner

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?

@kastork
Copy link
Author

kastork commented Apr 15, 2014

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.

@witoldsz
Copy link
Owner

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.

@alexcrown
Copy link

Jasig CAS has REST API. You can use it like this gist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants