I'm installing an environment where I had two Zope/Plone servers:
plone1 -> for web content & user authentication
plone2 -> for web applications
I want to implement SSO around both servers but I don't know how to do it. I try to modify login_next and setAuthCookie(..) to share the __ac cookie in the domain, but didn't work.
Anyone know the best way to achieve it!
Thanks in advance,
Oscar Sánchez.
I haven't done this yet, but may need to do so. So this is what I've gathered so far.
CAS
Plone as CAS server and as CAS client.
PubCookie
See the Pubcookie documentation.
Here's a writeup of setting it up with Plone: Single Sign On with Pubcookie
More on pubcookie and plone: Setting up Apache, Plone, and Pubcookie -- but there are some crucial gaps. In this case, the authentication provider is something called UWNetID, but they don't talk about configuring that. In your case, that would be a Plone instance.
mod_auth_tkt
See the mod_auth_tkt documentation.
It works with plone.session.
If both sites are on the same domain (but different subdomain), you can try to set the cookie on ".domain.tld". But I'm not sure if that will work - sending the original credentials as cookies is highly insecure, a session should be used in stead, and you can't share this session between two different instances.
Have you considered something like openid, possibly with your own private OpenID provider? That basically implements simple SSO out of the box.
Related
Here is the situation:
We use Flask for a website application development.Also on the website sever, we host a RESTful service. And we use Flask-login for as the authentication tool, for BOTH the web application access and the RESTful service (access the Restful service from browsers).
Later, we find that we need to, also, access the RESTful from client calls (python), so NO session and cookies etc. This gives us a headache regarding the current authentication of the RESTful service.
On the web, there exist whole bunch of ways to secure the RESTful service from client calls. But it seems no easy way for them to live together with our current Flask-login tool, such that we do not need to change our web application a lot.
So here are the question:
Is there a easy way(framework) so the RESTful services can support multiple authentication methods(protocols) at the same time. Is this even a good practice?
Many thanks!
So, you've officially bumped into one of the most difficult questions in modern web development (in my humble opinion): web authentication.
Here's the theory behind it (I'll answer your question in a moment).
When you're building complicated apps with more than a few users, particularly if you're building apps that have both a website AND an API service, you're always going to bump into authentication issues no matter what you're doing.
The ideal way to solve these problems is to have an independent auth service on your network. Some sort of internal API that EXCLUSIVELY handles user creation, editing, and deletion. There are a number of benefits to doing this:
You have a single authentication source that all of your application components can use: your website can use it to log people in behind the scenes, your API service can use it to authenticate API requests, etc.
You have a single service which can smartly managing user caching -- it's pretty dangerous to implement user caching all over the place (which is what typically happens when you're dealing with multiple authentication methods: you might cache users for the API service, but fail to cache them with the website, stuff like this causes problems).
You have a single service which can be scaled INDEPENDENTLY of your other components. Think about it this way: what piece of application data is accessed more than any other? In most applications, it's the user data. For every request user data will be needed, and this puts a strain on your database / cache / whatever you're doing. Having a single service which manages users makes it a lot nicer for you to scale this part of the application stack easily.
Overall, authentication is really hard.
For the past two years I've been the CTO at OpenCNAM, and we had the same issue (a website and API service). For us to handle authentication properly, we ended up building an internal authentication service like described above, then using Flask-Login to handle authenticating users via the website, and a custom method to authenticate users via the API (just an HTTP call to our auth service).
This worked really well for us, and allowed us to scale from thousands of requests to billions (by isolating each component in our stack, and focusing on user auth as a separate service).
Now, I wouldn't recommend this for apps that are very simple, or apps that don't have many users, because it's more hassle than it's worth.
If you're looking for a third party solution, Stormpath looks pretty promising (just google it).
Anyhow, hope that helps! Good luck.
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/
In my case I'm using the Dropbox API. Currently I'm storing the key and secret in a JSON file, just so that I can gitignore it and keep it out of the Github repo, but obviously that's no better than having it in the code from a security standpoint. There have been lots of questions about protecting/obfuscating Python before (usually for commercial reasons) and the answer is always "Don't, Python's not meant for that."
Thus, I'm not looking for a way of protecting the code but just a solution that will let me distribute my app without disclosing my API details.
Plain text. Any obfuscation attempt is futile if the code gets distributed.
Don't know if this is feasible in your case. But you can access the API via a proxy that you host.
The requests from the Python APP go to the proxy and the proxy makes the requests to the Dropbox API and returns the response to the Python app. This way your api key will be at the proxy that you're hosting. The access to the proxy can be controlled by any means you prefer. (For example username and password )
There are two ways depending on your scenario:
If you are developing a web application for end users, just host it in a way that your API key does not come to disclosure. So keeping it gitignored in a separate file and only upload it to your server should be fine (as long there is no breach to your server). Any obfuscation will not add any practical benefit, it will just give a false feeling of security.
If you are developing a framework/library for developers or a client application for end users, ask them to generate an API key on their own.
I have an application that will use flask and mongodb; I will probably host it on rackspace.
I need to understand how flask authenticating works. I have not found much information on the subject. Is there a complete tutorial on how to roll your own solution? If not, I certainly would like to hear some thoughts on how you would approach it for a a flask app.
Big PS:
I just thought about it. I also need to open a real API. A part of that API will be used for AJAX on the front end. How do i secure that part of the app?
Can anyone explain API auth requests?
I would suggest using the flask-login extension, it makes session management really easy to add to your flask application, and provides a nice documentation which covers in details every aspect of the extension.
I don't think that flask has any authentication built-in, only support for tracking sessions.
Here are some snippets for basic HTTP authentication and authentication with some third-party providers. Otherwise you will need to roll your own or use a framework that has this baked in (like Django)
Here is a discussion thread on this topic with a useful link
Flask-Login doesn't, technically, do authentication - it does session management, leaving the (tricky to securely implement) authentication details to you. Something like Flask-Security actually implements both session management and authentication (also nice-to-haves like password recovery/reset and the like), at the cost of having to have explicit support for your database.
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.