Can I share authentication across two sites from a single login?

[jbittel]

Can I share authentication across two sites from a single login?

[manelclos]

Hi Phil,

I'm successfully using mama-cas in the way you describe.

In my setup, this is what happens:

• I try to login into App1, I get redirected to the CAS login page
• I do login into the CAS, and I get redirected back to App1
• The CAS app has set a cookie so I'm already logged in, name it cas_cookie
• App1 receives the cas ticket, authenticates it against the CAS app and grants me login
• App1 sets a cookie so I'm already logged in into App1, name it app1_cookie
• I try to login into App2, I get redirected to the CAS login page
• Since I'm already authenticated because the browser sends the cas_cookie, I get automatically redirected to App2 without having to enter the login credentials again
• App2 receives the cas ticket, authenticates it against the CAS app and grants me login
• App2 sets a cookie so I'm already logged in into App2, name it app2_cookie
• At this point I have 3 cookies (cas_cookie, app1_cookie, app2_cookie) and I'm logged into 3 different apps.

There is no way to login out of App1 when login into App2.

On logout though, if you set clients to do a FULL logout, login out out of App1 will send a request to the CAS app to do logout which in turn sends logout requests to all services. And at this point the 3 cookies have been invalidated.

I recommend you follow the browser through redirects using the Chrome option "preserve log" and take a look at the cookies on every step.

Hope this helps!

[philsheard]

Thanks @manelclos - that's a great help. Mind if I ask another couple of quick questions?

• To get the cookies working in that way, have you done any extra coding to set and read the cookies within authentication? Or is this a setting in the client or server? At the moment I'm testing with a vanilla / basic setup and so haven't modified the authentication system at all.

• When you talk about FULL logout, are you suggesting that I need to deactivate this setting on either the clients? Or is OK for FULL logout and your setup to exist at the same time.

Much appreciated for the advice so far. If I can get this working, I will also try to make a pull request to add to the documentation for future people.

Phil

[manelclos]

Hi @philsheard,

The cookies are set automatically by Django, as with any other app, nothing special here.

I do have full logout enabled, because I think that is a more consistent user experience. Otherwise you will have to go to every app to log out. So yes, fully compatible.

I love doc PRs. At the time there are a couple of PR for Django 2.0 support. Hope maintainers can spend a bit of time soon :). The git repository you created could also be great for newcomers.

[philsheard]

Sorry, I'm a little more confused now 🙂 - if the cookies are automatically enabled, then do you have any suggestions about why my test flow isn't detecting them and forcing me to reset the login for each site?

I've seen that the returning URL from the django-mama-cas server has a ticket parameter, so perhaps do I need to change from a URL based validation to a cookie based approach? I appreciate the feedback you've given so far.

Sample return URL to local client: http://127.0.0.1:8081/accounts/login?next=%2F&ticket=ST-1517999732-2U5QHWgbG7TV82y6BXY89AsJWCreIMaE

[manelclos]

The cookies are used to check that you have a valid session with every app. So you have a cookie for the CAS app, a different one for App1, etc.

When you try to access App1 for the first time, there is no session cookie for App1. As you have configured App1 to use the CAS, you are redirected to the CAS app. First time there is also no cookie for the CAS app, so it asks you for credentials (let's say we are using username/password), and once you authenticate, it redirects you back to App1 with the ticket. That ticket is read by the CAS CLIENT and using an http request it is checked against the CAS SERVER. If the ticket is valid, the CAS client will log you in App1, which will produce the "side effect" of setting the session cookie for App1.

So next time you access App1, as you are already logged in, there is no need to check against the CAS app. Checking against the CAS app will only happen when the session cookie for App1 expires or you log out from App1.

When login into App2, you are redirected to the CAS app, as the session cookie for the CAS app is still valid (has not expired), you are NOT asked for credentials, you are ALREADY logged into the CAS app, so you get a redirect back to App2 with a new ticket that App2 will check. App2 will then log you in and set a cookie for App2.

If at this point you log out from the CAS app, session cookies for App1 and App2 are still valid, you can continue to use them, but if you try to login into App3, the CAS app will ask for credentials.

If you logout from App1, and you have FULL logout enabled, App1 CAS CLIENT will send a logout request to the CAS app, and in turn the CAS app will send logout requests to the other Apps (App2, App3 ...).

Watch the cookies as they are created, and play with deleting them and accessing apps or cas again. Along the "preserve log" option to see redirects, it will give you the full picture of what is going on.

[philsheard]

Thanks for the detail! Really helpful. I'll do some more testing today. This isn't the experience I'm getting so far (as the CAS cookies aren't auto-logging me in for the second app login) so I will inspect the cookies to try and understand why.

…

On 7 Feb 2018 11:01, "Manel Clos" ***@***.***> wrote: The cookies are used to check that you have a valid session with every app. So you have a cookie for the CAS app, a different one for App1, etc. When you try to access App1 for the first time, there is no session cookie for App1. As you have configured App1 to use the CAS, you are redirected to the CAS app. First time there is also no cookie for the CAS app, so it asks you for credentials (let's say we are using username/password), and once you authenticate, it redirects you back to App1 with the ticket. That ticket is read by the CAS CLIENT and using an http request it is checked against the CAS SERVER. If the ticket is valid, the CAS client will log you in App1, which will produce the "side effect" of setting the session cookie for App1. So next time you access App1, as you are already logged in, there is no need to check against the CAS app. Checking against the CAS app will only happen when the session cookie for App1 expires or you log out from App1. When login into App2, you are redirected to the CAS app, as the session cookie for the CAS app is still valid (has not expired), you are NOT asked for credentials, you are ALREADY logged into the CAS app, so you get a redirect back to App2 with a new ticket that App2 will check. App2 will then log you in and set a cookie for App2. If at this point you log out from the CAS app, session cookies for App1 and App2 are still valid, you can continue to use them, but if you try to login into App3, the CAS app will ask for credentials. If you logout from App1, and you have FULL logout enabled, App1 CAS CLIENT will send a logout request to the CAS app, and in turn the CAS app will send logout requests to the other Apps (App2, App3 ...). Watch the cookies as they are created, and play with deleting them and accessing apps or cas again. Along the "preserve log" option to see redirects, it will give you the full picture of what is going on. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAx3rgD9auOVn0SkD5CWNBc7o97HzMy0ks5tSYKcgaJpZM4R67yT> .

[manelclos]

Hi Phil, I fixed your example here: philsheard/django-cas-test#1

The problem you faced is that when running all apps (server and clients) on 127.0.0.1, even on different ports, all apps will use cookie name 'sessionid' and cookie path '/', so they were overwriting each other cookie.

Test now and let me know if it works for you.

[philsheard]

Thanks so much @manelclos - it was way above the call of duty to come back and help make sense of that. I really appreciate it.

I'll run a local test of this. It now makes sense that running them both on localhost could cause clashes, which you wouldn't have in a production setting. Thanks again.

[manelclos]

@philsheard is this issue fixed?

[philsheard]

Hi @manelclos - I've still not had chance to test this but I'm happy to close this off. Again, really appreciate you taking the time to resolve the localhost issue with me.

[manelclos]

Sure thing, no problem!

[agn-7]

Hello @philsheard

Is your problem solved?
Does your repository support Single Sign-On (one login for multiple app(s)) across your sub-app(s)?

[agn-7]

@philsheard

Apparently, @manelclos has forked your repo and sent a pull request to your repo. However, this is useful for Django version 1 whereas I'm using Django version 2, In this way, I used from the following procedure which worked for me well with Django 2:

1. A CAS-Client is needed so I used the new generation of Django-CAS called django-cas-ng package and here is its configuration to make your own client. (Also, here is a pre-configured client repo)
2. A CAS-Server is needed so I used a pre-configured repo.