Hi Carsten, I'll be limiting my answer to the most notable lines and quote only those.
(anybody else reading this without following the mails live: Go to the archive to see Carsten's full post) On 08.04.21 22:08, Carsten Klein wrote: > > Typically, those desired extra attributes are stored in the user's > record in the user database. That may be a SQL database or may be an > Active Directory Server (or any other directory), which is already > used for authentication and authorization. > > Wouldn't it be cool to make the Realm get us that extra information? It would be cool, absolutely. Even cooler if "the desired extra attributes" could be agreed upon - or even what would be desirable in user management (is user + roles enough? That requires redeployment any time the system gets more picky with permissions. Personally, I work with Liferay, where roles are runtime-configurable and map to permissions. The permissions are what's checked in the application code, and the applications couldn't care less about number of roles or path through which a permission is assigned to a user. > In its simplest form, these Realms get a new configuration property > 'extraAttributes', which takes a comma separated list of field names > to retrieve. Implicitly, for an SQL-based Realm, these fields are > queried from the 'userTable' table. The JNDIRealm tries to find these > attributes from the user's entry in the directory, of course. > > More complex configurations are possible (but likely not needed). You first state "its simplest form", then state that more complex solutions are likely not needed. I'd argue that the current form is "the simplest form", as it provides identifiers that can be used to look up extra information according to the application's need. I don't want to tear down your idea - only reflect that "only a little bit more" will be barely enough for the next person coming around, and end up being a really complex beast. And if you look at all the different available attributes for users that make sense in some, but not in other countries/cultures, you'll soon be implementing your own anyway: * What makes up the name? First/Last Name? Including middle name (common in US, almost nonsensical in Germany)? There are cultures with just a single name * Gender: How many choices and what will they be named (by law, Germany now has 3 genders) * Address: I've recently sent out letters to international addresses, and boy was it hard to ask for the right information to go to the address sticker. * Department: Makes sense in a business environment, not at all in a community environment While you name some samples that sound agreeable on first sight, I don't think that they're agreeable enough to impose them on people unless provided voluntarily and under arbitrary names. Which ends up with the cost of a huge framework in order to potentially save a single database request per log in. E.g.: It would be cool, but I don't see it worth the price. my 2 (Euro) Cent Olaf > > I'm curious what you think about it :) > > Carsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
