What are the pros and cons of using open id vs auth? Shoud I do both?
That depends whether you want to support Open ID. As to the reasons behind Open ID, in my view the most compelling one is that it avoids requiring your users to have an account just for your site, with all the hassle that involves (yet another username and password to remember).
If you decide you want to use Open ID, there's not need to choose between that and auth - use django-openid-auth, which adds Open ID support to the auth framework.
Definitely try and avoid using an Open ID implementation that doesn't plug into Django's auth framework - you'll lose a lot of the baked-in goodness of Django (model-level permissions etc).
OpenID and OAuth do different things. OpenID lets users log into your site. OAuth lets people give your site access to their data elsewhere. On the other side of the coin, OAuth gives you a secure way to let users access their data in your service from elsewhere.
If you implement OpenID, don't implement an OpenID producer. Everyone's already got an OpenID, whether they know it or not. Just consume openids from elsewhere. Migrating OpenIDs shouldn't be hard. Just make sure that a user account can connect via multiple OIDs, then they can add new ones as needed, and remove when they're done with them.
Edit: Just saw that you were talking about django auth, not oauth. Oops. The second paragraph still stands.
Related
The "Django-Rest-Framework (DRF) Throttling" can help to prevent bruteforce attacks and failed login attempts.
Then why do we need to use "Django axes", "Django defender", "django-ratelimit" or similar components?
Thanks In Advance
Throttling, as provided by DRF, is very different to Authentication, which is the focus of Django Axes.
In DRF you can allow access to your resource (say a database) for a defined amount of times (i.e. 100 database lookups) in a given period (lets say a day), so they are throttled to that amount/period, here 100/day. In some use-cases the user need not even identify themselves necessarily to avail of your service, there is no authentication involved -here you look at the IP of the users system as a key to throttle the users activity. Yes you can run throttling in conjunction with authentication in DRF, but one does not require the other.
Whereas in Axes you are primarily concerned with having the user prove his identity (authentication) through the login process. You can also instruct Axes to deny a repeat-failing user the opportunity to authenticate, i.e. if you fail to login correctly for 10 attempts you are now banned from logging in for the next 5 minutes. So typically a non authenticated user will never avail of your service and a repeat authenticate-failing attempts will result in that IP being denied the opportunity to authenticate for an extended time period. The emphasis with Axes tends to be on determining why a user failed to authenticate and by which means they gained access to the system. For example from the Axes reports, you can determine how many users logged in that day using the link emailed to them from the registration page. Or which users logged in using facebook, and also how many users failed to login (IP, username or email for example).
Furthermore, DRF is in effect an add-on to "regular django", and thus it´s throttling and authentication are tailored to the API service that it performs. Your users using an API are in general not likely to authenticate manually to the API but rather using some token (JWT,csrf) . Django Axes is also an add-on to regular django and typically services the needs of a typical web site with authenticating users. You can use both services, DRF and Axes on the one django platform, they work well together and do not clash.
As far as I know, those libraries you mentioned all do the same thing (with a few differences between them). You can choose the one which best suits your needs.
If you are using DRF, then you don't need an aditional library (axes, ratelimit, etc.) because DRF already has the throttling functionality build in.
I need a modern looking forum solution that is self hosted (to go with a django project)
The only reasonable thing I can see using is discourse, but that gives me a problem... How can I take care of auth between the two? It will need to be slightly deeper than just auth because I will need a few User tables in my django site as well.
I have been reading about some SSO options, but I am unclear on how to appraoch the problem down the road. here is the process that I have roughly in my head... Let me know if it sounds coherent...
Use Discourse auth (since it already has social auth and profiles and a lot of user tables.
Make some SSO hook for django so that it will accept the Discourse login
Upon account creation of the Discourse User, I will send (from the discourse instance) an API request that will create a user in my django instance with the proper user tables for my django site.
Does this sound like a good idea?
That sounds plausible. To make sure a user is logged in to both, you may put one of the auths in front of the other. For example, if discourse is in front of Django, you can use something like the builtin RemoteUserMiddleware.
In general, if they are going to be hosted on different domains, take a look at JWT. It has been gainining ground to marry different services and the only thing you need is to be able to decode the JWT token, which a lot of languages have nowadays in the form of libraries.
I have got an Django application that uses the RemoteUserBackend in combination with Apache and mod_auth_kerb to authenticate against Kerberos.
However, this has some drawbacks:
There is no proper logout without closing the browser tab. You may click "Logout" in your Django application, but I would expect to be asked for my credentials when I try to log in again - the latter is not the case. (Side note: It is quite possible for my application that two users want to log in one after another, which increases the lack of comfort and may be problematic when one users performs actions with the other user's rights.)
The application is currently tailored to the Apache/RemoteUser solution, so it does provide no flexibility to switch over to other authentication methods, e.g. authentication against the Django database. The possibility to use alternative authentication methods would also ease the development of the application.
That said, I would like to use a form-based authentication (username/password). This would move the control for the authentication to Django, so login/logout should work properly then. Also, this form could be used as well with different authentication backends, without a need to modify the GUI.
How can this be done? Is there already a solution to this or a project that adresses my issue? Most implementations I saw like the ones in the answers here just use Apache or an LDAP authentication, but not Kerberos.
Related, but unanswered question: Django user logout with remote authentication
Sorry this is delayed. I am the author of the above recommended Kerberos + Django post (roguelynn.com).
For your first issue, take a look at kobo: https://fedorahosted.org/kobo/ - it uses Kerberos + RemoteUserBackend + Apache with Django, but implements a logout mechanism (in kobo/django/xmlrpc/auth.py: https://git.fedorahosted.org/cgit/kobo.git/tree/kobo/django/xmlrpc/auth.py).
http://www.roguelynn.com/words/django-custom-user-models/
That blog post explains quite nicely how to use Kerberos as a Django 1.5 backend authenticator. Hot off the presses as of May 15th. She's got a bunch of nice kerberos examples.
For posterity's sake just in case the blog goes away someday, the author stores her blog posts as static files in her github repo.
https://github.com/econchick/roguelynn/blob/master/_posts/
I plan to use Google Accounts to authenticate users of my GAE app.
As i understand it, all owners of a gmail adress are considered equal and can be authentified.
My app providing a free trial mode that requires no login, i'm only interested to authentify my paying customers.
Maybe I miss something, but the only distinction between users mentioned in the docs is between admins/non admins.
What is the common practice to authenticate a specific class of users (in my case: paying users) in GAE?
Have a look at gae-biolerplate, it shows how to create a user class using different logins
If you want to have extra information on users use a new model ie UserExtra to add information
like ie paid etc
link to boilerplate
I need to add few more options for login and therefore need to customize create_login_url with some HTML code.
Is there a way to add on your code in default login screen of Google?
Environment: Python (Google App Engine)
I want to continue having the default Google ext class Users behavior in place.
You can't customize the login page. Allowing you to do so would introduce the possibility of XSS vulnerabilities, as well as making it harder for users to identify a legitimate login page.
If you want to provide for federated login, you may want to simply redirect users to an interstitial page that allows them to pick standard Google login, or one of a number of other services.
Nick Johnson recently released an alpha version of a WSGI middleware that you could use. The API is very similar to the standard Users API in app engine. It is a way to support auth via OpenID (something Alex Martelli suggested in his answer). Therefore you are able to support Google as Identity Provider as well as others. If you only want to support Google accounts for some reason, you could certainly only whitelist them though.
Nick's blog announcement also lists some things to consider (these might be deal-breakers for you):
Users are identified uniquely by their OpenID endpoint.
You can't construct a User object without specifying an OpenID URL.
Nicknames and email addresses are user-supplied, so they're not guaranteed unique or validated.
is_current_user_admin() is not yet implemented.
login: clauses in app.yaml are not affected by AEoid - they still authenticate using the regular Users API.
You might consider OpenID, through any of the various open-source app engine projects for the purpose, such as this one for Django.
You can't use the existing Users module with those (save perhaps with some serious hacking, but I have not attempted such feats and would not necessarily recommend them;-), but the various projects in question tend to offer usable replacements.
Making your own login pages is also not too hard with these approaches, of course, since you start with all the sources to the "OpenID consumer" you choose to use.
I don't know if all the domains you want to support are OpenID providers (though I don't see why any site supporting its own user logins wouldn't also be an OpenID provider -- it's easy and makes it more valuable for users to have logins on that site!-), but I hope this will take you some part of the way towards your goal!