Hello, Mike. I agree it's not a common situation, but I think some things are simpler than they seem; for example, if you have two metadata plugins (e.g., SQL and LDAP), they both would be used regardless of the successful authentication method.
If I got it all right, you'd need at least 5 repoze.who plugins: 1 identifier, the one that handles the login form. 1 LDAP authenticator. 1 SQL authenticator. 1 LDAP metadata provider. 1 SQL metadata provider. Of which only the identifier and the LDAP metadata provider should be customized. The identifier would be customized in order to remove everything after the at sign (e.g., "[email protected]" becomes "gustavo"). And the LDAP metadata provider would be customized to filter/process the attributes retrieved. This would be translated into Python as: http://pastebin.com/BGv7i5cU Or, if you want to make sure that it's save to remove everything after the at sign for internal users, you can customize both authenticators: http://pastebin.com/W35kJmeG I think that way everything will work. HTH, - Gustavo. On Jun 6, 8:20 pm, Mike Orr <[email protected]> wrote: > 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. -- 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.
