On Sun, Jun 6, 2010 at 6:12 AM, Gustavo Narea <[email protected]> wrote: > Hello, Mike et al. >> I finally ended up making my own demonstration site >> step by step following the various tutorials and application >> templates. But I needed to do a hybrid form of LDAP+database auth that >> didn't really fit with who's structure, and then I discovered the >> repoze.who-LDAP module is unmaintained. I think if I go back to >> who/what I'll write my own identity plugin (if that's the right term) >> rather than trying to shoehorn my needs into the existing LDAP, >> SQLAlchemy, and identity-properties plugins. But my needs are rather >> specific and unusual. > > You may also consider sending some patches for that plugin. I've > changed my mind and, although I won't develop it actively anymore, I'm > accepting patches now. For example, one of the things you needed back > then is available in v1.1a1 (the username alone instead of the full > DN): > http://code.gustavonarea.net/repoze.who.plugins.ldap/Changes.html#alpha-1-2010-01-03
Ok, I'll see, but I'm not sure how generally useful they'd be. My problem is the following. 1) Some users are internal and have LDAP accounts, and their roles are calculated from their LDAP properties. (Roles = metadata for the identity object, which will later be used for authorization. It also includes record IDs for users who have permission only to specific records.) 2) Some users are external, so their username, password, and roles are in a SQL database. 3) Some users are hybrid, in that their authentication is LDAP but their roles are in the database. (They have higher permissions than their LDAP properties would indicate.) This is indicated by a database record with a null password. 4) I distinguish internal vs external users by the syntax of the username. Internal users have to enter their full email address, because the domain indicates they're internal (i.e., authenticate via LDAP). This is to prevent two different users from having the same username, because there are thousands of LDAP users and we don't know when somebody joins or leaves or what future usernames will be. But we're getting pushback from users that they don't want to type the domain, which is different than how they log into other applications (those that don't have external users). So I'm thinking about just choosing a priority; i.e., consult the database first or consult LDAP first, and then deal with identical usernames when/if users complain they can't log in. (We could also use a separate form field to indicate internal/external, but users wouldn't like that either.) 6) The LDAP plugin puts the user's properties into the identity object I think, but I don't want to force the application to process the raw LDAP properties all the time, because they're obscure and squirrely. I want it to calculate the roles right when they log in, in the same format used for external users. It looks like I'd have to write a plugin for that. 7) The normal cascading seems to try one authentication method first, and use that if it succeeds, and otherwise try the other. It doesn't allow for the hybrid case where both succeed and their metadata is merged in the identity object. (Full name from LDAP, roles from database.) That's where it looks like I'd have to write a custom plugin that spans three or four of the standard plugins. 8) The whole identity structure (how the metadata is created and used) is not the way my application works. I'm not sure if changing the structure would lead to a reasonable compromise. So #7 and #8 may lead to generic patches, but I'm not sure if they'd be generic enough to be generally useful. On the other hand, I think other people may also benefit from a more flexible form of cascading and metadata handling.I'm not sure if I can design one that would make everybody happy, but if I can I'll send it in. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
