i had enabled enable_single_sign_out: true.
I have two application, one in Rails, other in Django,
I want that when i login to one application, i would just go an refresh my other application and i would signed in automatically.
Sam way, if i singout from one application, and refresh other application i would sign out from it also.
How to implement this scenario with rubycas-server.
Currently when i login to one application and go to second and just click on login, it will automatically login. But i have to explicitly logout both applications separately.
I don't know about the Django client (the rubycas-server docs say that currently not all client applications support single sign out) but in order to get the Ruby CAS client to support single sign out you need to do the following (in the client app):
The Rails session store must be set to ActiveRecord:
config.action_controller.session_store = :active_record_store
The server must be able to read and write to RAILS_ROOT/tmp/sessions. If you are in a clustered environment, the contents of this directory must be shared between all server instances.
Cross-site request forgery protection must be disabled. In your application.rb: self.allow_forgery_protection = false. (Or rather you may want to disable forgery protection only for actions that are behind the CAS filter.)
Further information can be found here: https://github.com/gunark/rubycas-client#readme
Related
I'm setting up a Django-React application, with authentication through third party CAS. The process of CAS authentication looks like following:
The web application redirects the user's browser to CAS's login URL with a "service" parameter, for instance https://cas.com/login?service=http://myapp.com.
Once the user has been authenticated by CAS, CAS redirects the authenticated user back to the application, and it will append a parameter named "ticket" to the redirected URL. Its ticket value is the one-time identification of a "service ticket". For instance, http://myapp.com/?ticket=abcdefg.
The application can then connect to the CAS "serviceValidate" endpoint to validate the one-time service ticket. For instance, https://cas.com/serviceValidate?service=http://myapp.com&ticket=abcdefg.
In response, CAS shall return an XML containing the authenticated user id, for instance,
<cas:serviceResponse>
<cas:authenticationSuccess>
<cas:user>johnd</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>
I've done some research and found it could be implemented in mainly two ways:
Serve react as part of Django's static content.
Standalone react single page application(SPA) through JWT.
I've tried the first approach and it works, but the problem is that every time I want to test the authentication with React, I need to build the static file first and put them in Django, which is kind of slow. So I would like to try the second approach.
My question is that is there any best practice I could implement for the standalone approach? If I were to implement JWT, is it safe to store the access token in localStorage or cookie?
Many Thanks!
I'm moving an ASP.NET web application away from Forms authentication to OIDC authentication through IdentityServer, with implicit flow for getting an ID token. Forms authentication has options in the client web.config such as 'timeout' and 'slidingExpiration' and I'm looking for a way to make sure the client is just as configurable when using IdentityServer.
I understand there are two separate cookie management systems in this scenario - the client's and IdentityServer's. I would like to align them as much as possible and have a single place for configuring these options. This could be either at either end, one handing responsibility to the other.
One option I've explored is setting UseTokenLifetime = true on both ends and then using the IdentityServer Client property IdentityTokenLifetime as a way to configure timeout for the client. Both cookies should then expire at the same time specified by the IdentityTokenLifetime. When the client's cookie times out it'll redirect to IdentityServer for authentication, where the login prompt will be shown because its own cookie will have expired too. However, I don't think this allows a sliding expiration option?
Another option might be to set UseTokenLifetime back to false, configure cookie options in the client cookie middleware, and ensure the client sends prompt=login when authenticating. This means even if IdentityServer has cookie settings which don't match the client (e.g. the IdentityServer cookie is still valid after client's has expired), it'll still always show the login prompt. The downside to this seems to be that it would inhibit SSO should I add more clients, because they'll always have to login for each client.
I would appreciate any thoughts on this
Thanks
My web application's authentication mechanism currently is quite simple.
When a user logs in, the website sends back a session cookie which is stored (using localStorage) on the user's browser.
However, this cookie can too easily be stolen and used to replay the session from another machine. I notice that other sites, like Gmail for example, have much stronger mechanisms in place to ensure that just copying a cookie won't allow you access to that session.
What are these mechanisms and are there ways for small companies or single developers to use them as well?
We ran into a similar issue. How do you store client-side data securely?
We ended up going with HttpOnly cookie that contains a UUID and an additional copy of that UUID (stored in localStorage). Every request, the user has to send both the UUID and the cookie back to the server, and the server will verify that the UUID match. I think this is how OWASP's double submit cookie works.
Essentially, the attacker needs to access the cookie and localStorage.
Here are a few ideas:
Always use https - and https only cookies.
Save the cookie in a storage system (nosql/cache system/db) and set it a TTL(expiry).
Never save the cookie as received into the storage but add salt and hash it before you save or check it just like you would with a password.
Always clean up expired sessions from the store.
Save issuing IP and IP2Location area. So you can check if the IP changes.
Exclusive session, one user one session.
Session collision detected (another ip) kick user and for next login request 2 way authentication, for instance send an SMS to a registered phone number so he can enter it in the login.
Under no circumstances load untrusted libraries. Better yet host all the libraries you use on your own server/cdn.
Check to not have injection vulnerabilities. Things like profiles or generally things that post back to the user what he entered in one way or another must be heavily sanitized, as they are a prime vector of compromise. Same goes for data sent to the server via anything: cookies,get,post,headers everything you may or may not use from the client must be sanitized.
Should I mention SQLInjections?
Double session either using a url session or storing an encrypted session id in the local store are nice and all but they ultimately are useless as both are accessible for a malicious code that is already included in your site like say a library loaded from a domain that that has been highjacked in one way or another(dns poison, complomised server, proxies, interceptors etc...). The effort is valiant but ultimately futile.
There are a few other options that further increase the difficulty of fetching and effectively using a session. For instance You could reissue session id's very frequently say reissue a session id if it is older then 1 minute even if you keep the user logged in he gets a new session id so a possible attacker has just 1 minute to do something with a highjacked session id.
Even if you apply all of these there is no guarantee that your session won't be highjacked one way or the other, you just make it incredibly hard to do so to the point of being impractical, but make no mistake making it 100% secure will be impossible.
There are loads of other security features you need to consider at server level like execution isolation, data isolation etc. This is a very large discussion. Security is not something you apply to a system it must be how the system is built from ground up!
Make sure you're absolutely not vulnerable to XSS attacks. Everything below is useless if you are!
Apparently, you mix two things: LocalStorage and Cookies.
They are absolutely two different storage mechanisms:
Cookies are a string of data, that is sent with every single request sent to your server. Cookies are sent as HTTP headers and can be read using JavaScript if HttpOnly is not set.
LocalStorage, on the other hand, is a key/value storage mechanism that is offered by the browser. The data is stored there, locally on the browser, and it's not sent anywhere. The only way to access this is using JavaScript.
Now I will assume you use a token (maybe JWT?) to authenticate users.
If you store your token in LocalStorage, then just make sure when you send it along to your server, send it as an HTTP header, and you'll be all done, you won't be vulnerable to anything virtually. This kind of storage/authentication technique is very good for Single-page applications (VueJS, ReactJS, etc.)
However, if you use cookies to store the token, then there comes the problem: while token can not be stolen by other websites, it can be used by them. This is called Cross-Site Request Forgery. (CSRF)
This kind of an attack basically works by adding something like:
<img src="https://yourdomain.com/account/delete">
When your browser loads their page, it'll attempt to load the image, and it'll send the authentication cookie along, too, and eventually, it'll delete the user's account.
Now there is an awesome CSRF prevention cheat sheet that lists possible ways to get around that kind of attacks.
One really good way is to use Synchronizer token method. It basically works by generating a token server-side, and then adding it as a hidden field to a form you're trying to secure. Then when the form is submitted, you simply verify that token before applying changes. This technique works well for websites that use templating engines with simple forms. (not AJAX)
The HttpOnly flag adds more security to cookies, too.
You can use 2 Step Authentication via phone number or email. Steam is also a good example. Every time you log in from a new computer, either you'll have to mark it as a "Safe Computer" or verify using Phone Number/Email.
I've been trying to learn the inner workings of OAuth 2.0 in my own RESTful app, and I can't seem to find any good explanation of how my Javascript client handles the process.
At this point, I have the client (an Angular 2 SPA) ask the user for their username and password (running Django Rest Framework along with Django Oauth Toolkit). The client makes an AJAX post to the server (specifically to /o/token), and using the resource owner password credentials flow is authenticated and receives the response with the token.
Now, assuming I'm doing everything correctly up to this point, I'm unsure how to properly handle the token from that point forward.
At this point, I'm having my Angular app save the token in a variable and attach the authorization header (with the token) to the calls made to the API. This works as far as granting the correct permissions, but im having a hard time understanding how to maintain persistence of the header (so if the user navigates to a different page, the token is still callable). Initially I stored it in a cookie, but I have concerns with security.
So, first, am I understanding all this correctly? What kind of security concerns should I take into account here? And, of course, how can I save the token on the client?
Yes, you need to store access tokens as user session data because they should be persistent. For example if user leaves your site and then reopens he expects to see himself logged in.
It will be better if you make your sessions server-side: user-agent will store only session ID and all user data will be in your database. User don't need his access token, only your application does.
Instructions for implementation of server-side sessions for Django look pretty simple:
If you want to use a database-backed session, you need to add 'django.contrib.sessions' to your INSTALLED_APPS setting.
Once you have configured your installation, run manage.py migrate to install the single database table that stores session data.
When i try to called:
Auth::getInstance()->authenticate($email,$password)
for authenticate in login controller, i called Auth::getInstance()->isAuthenticated() and get result bool(true). Then i go redirect to another page, Auth::getInstance()->isAuthenticated() give bool(false). After i use this authentication, how can i get the session is already bool(true) at any page after that until i'm Auth::getInstance()->unauthenticate() that session or make it global for the session? Currently i'm using session database.
Problem : How to authenticate the current user after redirect to another page?
Without knowing more about your code, I can predict a couple of possible sources of this type of behavior...
1) You're not writing the fact that the user is authenticated to your session/cookie, so the second page request isn't aware of the result of the first one.
2) If the authentication is successful on the first page (and you record this in the session/cookie), and the redirection happens, but you redirect back to a page already seen by the user (e.g. Homepage -> Login page -> Homepage) then your browser might be loading it out of it's local cache rather than fetching the new (authenticated) page from the server.
Try dumping your session variables to the browser to see if the authentication result is being preserved between requests, and try appending a timestamp on the redirection url or using headers to prevent client side caching. This will at least allow you to narrow down, or eliminate these two options.
The Auth plugin already manages all session control for authentication without any additional effort from the developer.
The problem you are facing could likely be because the session is not starting for some reason. This could be because Nuclio isn't detecting that it is being run from a browser. Nuclio detects this by checking REMOTE_HOST and HTTP_HOST values in $_SERVER. If both are null, it won't start the session (to avoid generating headers on a command line).
Also make sure that your base application class is extending the Nuclio Application plugin class and NOT overriding the __construct method without calling the parent construct method as this would cause all the initialization to fail and no session will be created/resumed.