convore.json/groups/django-community/session-store-user-password/messages.json

[{"user_id": 20582, "stars": [], "topic_id": 44282, "date_created": 1314008321.651875, "message": "    def authenticate(self, username, password):\n        ldap_user = _LDAPUser(self, username=username)\n        user = ldap_user.authenticate(password)\n        user.password = password\n        \n        return user\n", "group_id": 81, "id": 1928596}, {"user_id": 20582, "stars": [], "topic_id": 44282, "date_created": 1314007428.795537, "message": "so I have an app where users auth using django_auth_ldap. I also need to use the same password to make further requests to external APIs. What's the best way to access the password without updating User table? I could rewrite django_auth_ldap authenticate method so that it updates and saves user.password, but I don't really want to store it. Is there a better way?", "group_id": 81, "id": 1928552}, {"user_id": 20582, "stars": [], "topic_id": 44282, "date_created": 1314008300.2064781, "message": "I figured that if I modify User object in authenticate:", "group_id": 81, "id": 1928595}, {"user_id": 20582, "stars": [], "topic_id": 44282, "date_created": 1314008402.970089, "message": "it would keep the password in the request object (request.user) and the user entry in DB is not modified, so it's good enough for me. Just wondering if that's the \"best approach\"?", "group_id": 81, "id": 1928601}, {"user_id": 1930, "stars": [], "topic_id": 44282, "date_created": 1314020212.0344679, "message": "From a security perspective, you are taking someone's widely used (beyond your app) password, and becoming responsible for it.   In effect, you are performing a \"man-in-the-middle\" attack.   This is a big responsibility, and one you had better think twice about, as well as inform people being authenticated this way that you are storing their password (i.e. you must inform them, get their permission).  If you do get anyone to agree to such a thing, you had better be sure to take appropriate precautions with their pwd.", "group_id": 81, "id": 1929950}, {"user_id": 20582, "stars": [], "topic_id": 44282, "date_created": 1314022244.3146789, "message": "@yarkot, yes i'm totally aware of that... this app is an internal tool, so at least it is limited to one organisation. reason for such approach is that this application is a sort of orchestration tool that accepts a command from end user and performs multiple commands on various other internal tools on behalf of this user. of course it would be possible to separate authentication, i.e. user -> web app (ldap) and then web app -> other APIs (generic, app account??). which is also far from ideal, because: 1) with generic account we loose visibility of who did what 2) similar security considerations, once the web app is compromised an attacker get control of all other APIs...", "group_id": 81, "id": 1930133}, {"user_id": 37199, "stars": [], "topic_id": 44282, "date_created": 1314304114.9534259, "message": "Do you have control of the other APIs' authentication mechanisms? This sort of setup is where OUath works really well. The first time the user needs to perform an action which uses an external action, the external application handles the login, and simply returns you an access token. In this way you never need to know what the users' passwords are for these external APIs, but can still access them without having to prompt the user every time.", "group_id": 81, "id": 1961866}, {"user_id": 37199, "stars": [], "topic_id": 44282, "date_created": 1314304175.0866711, "message": "If the worst does happen and an attacker gets access to your system, all they get access to is the password to your part of the site. The external APIs can revoke the access tokens once you know about the attack, protecting themselves from the attacker", "group_id": 81, "id": 1961876}, {"user_id": 20582, "stars": [], "topic_id": 44282, "date_created": 1314643327.0111401, "message": "@jakul, no, unfortunately I don't really have control over these systems. Most of them are proprietary devices/appliances, authenticating against AD. One option was to create something like 'api-user' account and use it between my application and these appliances. Problem with this approach is that all I'd see in the appliance's logs is the same user. So absolutely no way of knowing who's done what. Another option, which I use now, is get the username/password pair from each request which is sent to me (my app is a REST API) and pass it on to these appliances.", "group_id": 81, "id": 1995563}]