On Mon, Jan 4, 2010 at 11:31 AM, Joscha Feth <[email protected]> wrote: > Chris Anderson wrote: > >> My first thought is that there's got to be some common identifier in >> your LDAP space (like a UUID or something) that is the real identifier >> here. But I'm just guessing, maybe there's not... > > There is a UID I could use - but my idea was to leave this a little > more open, so users do not necessarily need to be part of that single > LDAP directory - there might be additional directories added by time, > so I needed to find something unique - and thats the email address (at > least for my scenario). > >> > Another question I didn't find anything about in the docs: is it >> > intended to store additional properties within userCtx beside .name >> > and .roles? >> >> I'm still on the fence about that. Reasons like your LDAP >> extensibility mean maybe we should allow more fields. On the other >> hand, I can imagine people abusing that and getting themselves stuck >> in a land with weird security bugs. >> >> Damien has mentioned to me the idea of a site security object, which >> would be stored in the database, and passed to validation functions. >> This would allow the validation function to know things like: "this >> application's authorization is implemented in terms of roles like >> author and editor. this site's authentication gives users roles like >> employee and manager. for this site, lets map employees to authors and >> mangers to editors." >> >> I don't know if this quite does the trick for you. I think I need to >> understand the first question (is there a real ID for your >> multi-named users?) before I get much further. > > so I guess the answer would be no - at least no natural one which would > help me do the trick here. >
Perhaps the best option here would be to allow authorization plugins to add extra fields to the userCtx. so you'd have userCtx.email_addresses be the list of addresses for a user. To normalize this we could send the entire user document from the users db to the validation function. The downside I can see is this might encourage app developers to use the extensibility even when they don't strictly need it, which could have a negative effect on interoperability. I'm still curious about the multiple email addresses issue... maybe it's more like the user has the ability to authenticate as any of those addresses, but for a given operation, they should pick one? Chris -- Chris Anderson http://jchrisa.net http://couch.io
