I am building a tool, in django, for a client's web site.
The tool I am building requires users to be signed in to an existing account.
User-authentication is handled by legacy software on another vendor's servers.
I can contact the programmer who wrote the legacy software (I am unsure of their development environment), but I am not sure what to ask for -- what hooks, api, rpc, etc. do I want?
Is there a design pattern for this type of situation? And what features of django should I use or extend to make this as straightforward as possible? REMOTE_USER sounds like the right thing, but I am not sure how I would use it in this case.
I'd recommend using jquery requests. You can send the username and password (encrypted, of course) to the remote site and get back a cookie/session key.
If you have access to the database, I'd also recommend doing that. For example, if the remote host is using MySQL, ask to have a view created for your user and then you can authenticate directly. With this approach, however, you may have to set up a MySQL connection outside of settings.py.
Two approaches:
1) API: If they have released their API, it would be much more simpler, you authenticate user using their API.
2) Expose Database: If they don't have API, they should must give their access to their database so that you can go in and authenticate. But while doing this keep in mind several things: Django authenticate() won't work, because by default authenticate method authenticates again auth_user table. You can of course manually authenticate using your own logic but that would be problem too: you have to create your own sessions and stuffs. So your option is to use custom user models (only available from Django 1.5) in Django.
I am sure other may have better solution than this.
Related
I love PyCharm, so I thought I'd give YouTrack a try.
I used run-docker-container-as-service instruction, and I was able to create a service. I can start and stop the service with no issues.
Using a browser, I was able to do configuration, I can create users, issues, etc.
On the same system (Ubuntu 18.04.3 LTS) I'm also running a django application. I would like for my django application users to submit issues, check status on issues, and possibly update issues they have submitted.
I want to make it as simple for my users as possible, so I would like to use django authentication for my YouTrack. That way, once a user is logged into my application, they don't need to go through a separate authentication process to use YouTrack.
It seems YouTrack offers multiple different authentication methods, but I don't see a django option. Is it possible?
Unfortunately, there is no option to use Django authentication for YouTrack. The only option that came to my mind is a vice versa scenario with configuring YouTrack as a SSO provider and use the django plugin for your application for authentication purposes.
I'm new to Django and relatively new to OAuth. I'm building a Django app that's basically aiming to be a wrapper around Google Drive that implements tagging and user permissions. A few users who have important documents share them with the service account, and then the app provides a nice interface.
I'm generally confused about how to organize this, since Django seems to have many, many moving parts.
The app needs to almost constantly be authenticated with and talking to the Google Drive API.
Where does this authentication go? A model? Is it part of a site template that gets inserted on every page?
Here's sample app of integrating Django with OAuth2. You especially want to take a look at this file where it saves user credential using Storage class. There is also a documentation with better explanation about how OAuth flow with Storage works in Django.
To answer your question, you would want to define credential at Django user profile in order to save it easily associated with users. Also, your OAuth flow (creating auth url and authenticating) works at view.
I am working on a cross platform app that will be created using C++-> mobile devices, and using Perl-> Desktop PCs (like Windows /Linux/Mac OS).
Now, since the app will be downloadable, I have concerns regarding the ability of hackers to obtain the source code of my app.
Specifically, the app will connect to my central database-- at the minimum, I want that hackers are not able to obtain my database connection details. Ideally, I would want no part of the code to be hacked.
Basically, the user can update some of his information using this app-- if hackers get hold of this data they can easily change any unfortunate user's data. One thing that I have thought of is that the user will have to initially authenticate with OAuth/OAuth2 ( using his email ID #yahoo/#hotmail/#gmail)-- and only after that the app will actually show the admin interface. But at any rate, at some point the app will connect to the central database-- which is why I dont want the database's access details to be compromised.
Many organisations make such apps, so they must be facing this type of problem themself? I would like to know how I can protect my app (ideally entire code), and atleast the db credentials.
The simple answer is you do not expose your database. Ever.
Add a service layer (could be HTTP-based but doesn't have to be) on top that will deal with authentication and authorisation. Your app then logs in using the user's credentials and acts on their behalf. Your service layer exposes an API which your application talks to, but your service makes and controls all calls to the DB.
You already mention OAuth - that's a perfectly acceptable way of adding authentication to such an API.
You cannot.
On the bright side you can put security on your server. The connecting client provides credentials that they are a given user. The server generates the SQL command after proving the request is allowed. Backers can do anything your app can do, but your app becomes incapable of behaving badly to your database.
The previous answers are absolutely correct. You want a server based service layer that provides the authentication/authorization code and interacts with the database. However, it isn't always a perfect world and if you are stuck with the requirement that these applications must act as a database client you want to limit the exposure as much as possible. Typically this is done by having the client use a specific account which has not been granted any access to the general database. You then create specific stored procedures that can only do the operations and queries that are required of the application. This prevents anyone finding the credentials in the code from doing anything in the database that isn't intended, but you still have the problem that anyone can impersonate someone else by reviewing the code. There isn't a way to prevent that without a server side component. This might be okay for a closed/trusted group of users, but I wouldn't release anything to the general public with this method.
If you can do it, use OAuth2 and allow a trusted third party handle authentication. Twitter, Facebook and GitHub are all relatively paranoid about security; and the other poster is correct: never expose direct db access as part of the app the user has access to; put it behind a service of its own.
Good luck! :)
I am trying to build an application that will use data from multiple social services. The user will need to authorize their accounts to be accessed across these multiple services (e.g. facebook, twitter, foursquare) using oauth.
I don't really need the users to login with these accounts, really it is just allowing their data from the api to be pulled.
I know I need to use oauth, but I am having trouble finding a basic example of how to do this type of thing (a lot of examples exist for logging in with oauth).
I have been trying the python-oath2 library.
Does anyone have any recommendation for a good tutorial or example of doing this type of thing in python, and if possible django.
Thanks.
Why reinvent the wheel? There is a plethora of reusable applications that have this implemented. You can find a comparison here: http://djangopackages.com/grids/g/authentication/
Why not give rauth a try? We use this in production for this exact purpose. Although you don't need to require the user to login with your app via the provider, you're going to redirect to the provider, where they'll be asked to authenticate your application. Assuming they accept (or even if they don't), they'll be redirected back to your application, i.e. via the redirect_uri or oauth_callback, there you'll ensure they authorized your app and then proceed with whatever housekeeping you need to do, e.g. saving some info about the user in your database. Try the examples and also pay particular attention to the Facebook example. Now the Facebook example is intended for authorization with the example web app, but the same pattern can be used for what you're trying to do. (You just won't be having them login in via Facebook, for instance. However, the flow can be and probably should be identical, sans database operations and template login lingo.)
How would you implement a system with the following objectives:
Manage authentication,
authorization for
hundreds of thousands of existing users currently tightly integrated with a 3rd party vendor's application (We want to bust these users out into something we manage and make our apps work against it, plus our 3rd party vendors work against it).
Manage profile information linked to those users
Must be able to be accessed from any number of web applications on just about any platform (Windows, *nix, PHP, ASP/C#, Python/Django, et cetera).
Here some sample implementations:
LDAP/AD Server to manage everything. Use custom schema for all profile data. Everything can authenticate against LDAP/AD and we can store all sorts of ACLs and profile data in a custom schema.
Use LDAP/AD for authentication only, tie LDAP users to a most robust profile/authorization server using some sort of traditional database (MSSQL/PostgreSQL/MySQL) or document based DB (CouchDB, SimpleDB, et cetera). Use LDAP for authorization, then hit the DB for more advanced stuff.
Use a traditional database (Relational or Document) for everything.
Are any of these three the best? Are there other solutions which fit the objectives above and are easier to implement?
** I should add that almost all applications that will be authenticating against the user database will be under our control. The lone few outsiders will be the applications we're removing the current user database from and perhaps 1 or 2 others. Nothing so broad as to need an openID server.
Its also important to know that a lot of these users have had these accounts for 5-8 years and know their logins and passwords, et cetera.
There is a difference between authentication and authorization/profiling so don't force both necessarily into a single tool. Your second solution of using LDAP for authentication and a DB for authorization seems more robust as the LDAP data is controlled by the user and the DB would be controlled by an admin. The latter would likely morph in structure and complexity over time, but authentication is just that authentication. Separation of these functions will prove more manageable.
If you have an existing ActiveDirectory infrastructure, that will be the way to go. This will be particularly advantageous to companies that have already had Windows servers set up for authentication. If this is the case, I'm leaning towards your first bullet point in "sample implementations".
Otherwise it will be a toss-up between AD and opensource LDAP options.
It might be not viable to roll your own authentication schema for single-sign-on (especially considering the high amount of documentation and integration work you might have to do), and obviously do not bundle your authentication server with any of the applications running on your system (since you want it to be able to be independent of the load of such applications).
Goodluck!
Use LDAP/AD for authentication only, tie LDAP users to a most robust profile/authorization server using some sort of traditional database (MSSQL/PostgreSQL/MySQL) or document based DB (CouchDB, SimpleDB, et cetera). Use LDAP for authorization, then hit the DB for more advanced stuff.
We have different sites with around 100k users and they all work with normal databases. If most applications can access the db you can use this solution.
You can always implement your own OpenID server. There is already a Python library for OpenID so it should be fairly easy.
Of course you don't need to accept logins authorized by other servers in your applications. Accept credentials authorized only by your own server.
Edit: I have found an implementation of OpenID server protocol in Django.
Edit2: There is an obvious advantage in implementing OpenID for your users. They will be able to login to StackOverflow with their logins :-)