In the context of a e-health related service, the end-users (health operators, doctors and physiotherapists) working in the same physical environment and sharing just one client PC to interact with my backend, asked me to provide them with a mechanism to quickly switch among different accounts (security is not a concern most of the time because they are used to work within a LAN but, occasionally, they might work from remote clients, so I must keep an authentication/authorization backend in place). They would log in just once and then, before using the web application, would select their logged-in account from a combobox (sort-of).
The UI model might be the same as in GMail where it's possible to keep multiple logged-in user accounts and switch between them through the account selector in the top right corner.
I'm no django-authentication expert, so I am not able to even tell whether this is possible in the context of a django based app.
Does anyone know of any ready-made app/middleware to get this done? Or maybe point me in the right direction if I have to extend or modify existing code?
Thanks a lot.
I haven't looked for any existing solution for this, so this is how I would go about it from scratch.
You'd need to add storage to the user session to hold multiple users. Currently it looks much like:
{'_auth_user_backend': 'membership.auth_backends.MyCustomAuthenticationBackend',
'_auth_user_hash': 'e2c8ecf1e7ecdbd<snip>',
'_auth_user_id': '3806'}
and I would add an array to the session:
logged_in_users = [{'_auth_user_backend': ... }, {}, {}] # one auth dict per user
Then when you "switch users", edit the session object to move that user's auth details (id, hash and backend) into the top-level ones in the session.
You'll also have to write a custom login function that stores the login into the logged_in_users array, and takes out the bit in the current login function that flushes your session if the key is the same as the session of a different logged in user. Similarly, you'll need to think what happens when you logout.
Related
I have created a login app that is responsible for the login of other five applications. So when the user correctly authenticates in the first login, he can access all the other apps.
I have achieved this using the same cookie name for the login app and all the other applications.
But only one of this applications must be accessible from the outside
too, and not only from the login page. So it must have his own login page.
Question:
Is there a way to make this application accessible in two ways?
One way coming from the login application and the other way from its own login page?
Or I must have two separate applications?
Thanks.
So, this "login app" is used as a menu which enables users to access 5 different applications. Those are, I suppose, Apex applications.
If that's so, make the link (i.e. URL) to the one that has to be accessible "outside" of the login app available to users separately. All of URLs are the same, aren't they? You only change the APP_ID value.
Now, the problem might arise with the way of authentication. How did you do that? If it is user-defined, and "available" only in the login app, then you'll have to make it available to that separate application as well. Otherwise, users won't be able to connect to it. Lucky for you, you can create a new authentication scheme as a copy of existing one.
Though, underlying database objects (such as table that stores usernames and passwords, functions and procedures used to create new users and fetch data about existing ones, password validations etc.) will also have to be accessible to another database user. That can be done by granting appropriate privileges (SELECT, INSERT, UPDATE, DELETE on table(s), EXECUTE on stored procedures).
Therefore, no - I don't think that you should maintain two exactly the same copies of that application to make it work.
I'm using Ember 2.3 with Ember Simple Auth 1.0 and am wondering if anyone had any suggestions on the best approach to handle the following situation:
With the particular industry my platform serves, most staff are actually independent contractors and therefore could belong to multiple businesses. With that said, I have some specific requirements that I'm trying to address:
Avoid having to create a separate account with separate credentials for each business the staff member belongs to.
Allow credentials to be revoked at any time for a particular account.
Allow for account-level permissions.
Make it simple to switch accounts from inside the application without having to fully-reauthenticate.
To achieve this, my initial implementation is based around issuing a single JWT (using ember-simple-auth-token) for each user account. The proposed authentication flow would be as follows:
User logs in with username and password
System authenticates and if credentials are valid, return a token for each account.
If the system returns no tokens, return an error.
If the system returns a single token, use that token by default and redirect to the authenticated area of the site.
If the system returns more than one token, display a list of the accounts associated with those tokens and allow the user to choose the one in which they will be assuming the role of at that point.
What to do when the system returns more than one token is where I have questions:
Is there a way to "intercept" to allow the user to choose which account/token to use before ESA commits the token to the session in local storage?
If I want the user to be able to switch accounts, is it just a matter of swapping out the token value in local storage?
If there's anything else I should consider, I'd appreciate the feedback. If you also happen to think this is a terrible approach and have some feedback, I'd absolutely love it.
Cheers.
From ESA's perspective the user would be authenticated when the backend responds with one or more tokens (you'll have to implement a custom authenticator and authorizer of course). The fact that the session actually contains multiple tokens for multiple accounts isn't relevant for ESA really - that would be sth. that you'd need to handle in your application code instead.
Once the session is authenticated with one or more tokens, you can access them via the session's data.authenticated property, e.g. this.get('session.data.authenticated.tokens') etc. You could store the currently active account the user wants to use in the session's non-authenticated area, e.g. this.get('session.data').set('activeToken', 'whatever').
I am creating a saas, software as a service site with django.
Due to the project requirements the users are inside schemas/tenants, for that im using the fantastic django-tenant-schemas app, one user can have accounts inside different schemas (they share username and password) ... i want to let the user move throught the different schemas they are in more or less freely ... for that i have created a view where the user can select on what schema he wants to be on.
When i use an application wide cookie session that is when i have the cookie setting as ".domain.ext" (django documentation) that works fine but its NOT the behaviour we really want for our application.
What we really need is to be able to have different versions of the app on different browser tabs.
So we have to set the cookie configuration to "domain.ext", then everything breaks because the original view is on one tenant and the next view (where the just logged user really belongs) is inside other tenant then the old cookie is deleted.
So the question is how can i programmatically set the cookie correctly on the new view so the user that really belongs to that tenat is still authenticated.
Or is there any alternative approach we could use for that? Any examples?
EDIT TO CLARIFY as demanded:
Person A belongs to 2 schemas SH1 and SH2 on both of them he has the same username and password.
On every password change the password hash is replicated on all the schemas they belong to so they dont have to remember specific passwords or usernames.
When the person is logged on SH1 the url will be sh1.domain.com when he is logged on SH2 the url will be sh2.domain.com
So lets say the person is now logged on schema SH1, he decides to switch to schema SH2, to be able to do that i need the user to still been authenticated so that view has to be on the SH1 schema, but then its redirected to the new schema force authenticating the user but since the cookie is set as domain specific (default django behaviour) when the user lands on the next url sh1.domain.com/whatever the previous cookie is deleted and thus he has to log in again to be able to access.
If I'm understanding correctly, you want the ability to have the behavior of a cross-domain cookie, but without actually using a cross-domain cookie.
The immediate answer that comes to mind is "well, use a cross-domain cookie". This is pretty much the vanilla example of a situation where you'd want to use use a cross-domain cookie. Engineering a complex solution so that you can avoid using the simple solution never ends well :-) Unless there's some other constraint in play that you haven't revealed, I'd start by questioning whether you shouldn't just be doing this the easy way.
However, assuming there is a good reason (and, frankly, I'd be interested to know what that is), the problem you're going to face is that browser security is essentially trying to stop you doing exactly what you're proposing. You want to know, from domain SH2, whether something has happened to a cookie set on domain SH1. That's exactly the situation that cookie security policies are designed to prevent.
The only way you're going to be able to work around this is to have a third party that can share knowledge. When user A logs into SH1, you do password authentication as normal - but you also post a flag somewhere that says "User A is now on SH1". When A logs into SH2, you post the corresponding flag. If A goes back to SH1, you check against the central source of truth, discover that they're currently on SH2, and force a login.
You probably could do this by manipulating cookies and session keys, but I suspect an easier way would be to use an Authentication backend. What you'll be writing is an authentication backend that is very similar to Django's own backend - except that it will be making checks of cross-domain login status against the central source of truth.
How you implement that "source of truth" is up to you - an in memory cache, database table, or any other source of data will do. The key idea is that you're not trying to rewrite cookies so that the same cookie works on every site - you're keeping each site's cookies independent, but using Django's authentication infrastructure to keep the cookies synchronised as a user moves between domains.
I am working on SPA AngularJS application which allows users to collaborate on projects and stores history of edits for each user. The requirement is to allow unauthenticated users to manipulate data too. Once the user registers, I need to associate her history of edits with the newly created account. The backend is Django.
What is the best option to track actions of anonymous users?
I can create “anonymous” user at the firs visit, issue JWT, store it in the browser and use to track all the user’s activity. Later on when registering user, just update her profile.
The drawback is that there is a potential to get a lot of orphaned users that need to be periodically cleaned up.
This is similar to https://github.com/danfairs/django-lazysignup, but adapted to work with https://github.com/GetBlimp/django-rest-framework-jwt.
Use JWT or cookie to track user session. Allow using session identifier instead of user key to track user’s activity. When creating real user update all references to the session with user’s pk.
Anything else?
From my experience go for solution 1. The orphan user is often not a problem because from business plan point of view it's user and the more is better.
Also having only a notion of user is really simpler. They are users who haven't fully completed their profile that's all.
I have an application that is run on multiple user systems, and using OAuth, allows the users to log in via Facebook, Twitter, etc. The entire point of the user logging in is to get settings and actions that the same user made while logged in on other computers, as identified by logging in with the same OAuth provider + provider user id. The application itself is written in C++ using Qt.
My question is this: how can I save the settings that a user made, and allow them to retrieve it in a secure way? I have a centralized server that I can store information using MySql tables, but I'm not sure the best way to have the user application prompt the server, and receive the data stored for that user.
Any ideas or places you could point me towards?
There are several ways I could think of with this, all have trade offs:
Generally I would store the data in mysql using some kind of string or object encryption/serialization method. I do not use Qt much but http://qt-project.org/wiki/Simple_encryption has some examples of very simple encryption that could be used.
Then the question becomes: What do you use as the key? I would go either with the key provided by OAuth for that user (which could be an issue if users de-authorize the app but still want access to this data) or some other user provided key (which is counter to using OAuth in the first place).
Another option is to go with Qt Users session http://qt-project.org/doc/qt-4.8/qtwebkit-guide-cache.html
This would maybe remove the need to encrypt since it should only be accessible within the users scope.
NOTE: Based on comments below it seems the issue is more about securing communication with the MySQL versus the data inside of MySQL. Waiting on user comments to revise my answer.