Hi Olaf,
also, I only picked your statements for an answer.
On 08.04.21 13:53, Olaf Kock wrote:
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.
I'm not sure whether I got you right. For my mind, my idea has nothing
to do with authorization, roles and permissions. Also, I don't think
that the set of desired extra attributes is something that could be
agreed upon. It's rather very specific for a project and/or customer.
The basic idea is just to get some of the user's attributes/properties
for (any/free) usage by the application. Actually this proposal only
(ab)uses the Realm, since it already has configured access to a storage,
that one might call the 'user database'.
However, these attributes are only used by the application. These are
not used for authorization or grant of permissions.
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.
What can be simpler than a comma separated list of field names? If we
can agree upon the set of desired user attributes (which we can't
surely), no configuration will be required. That's would be simpler but
won't work, since every user database is different and desires are too.
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
That's why I recommend that the desired attributes must be specified in
a list. That list can be seen as the SELECT clause of an SQL statement
(but this will work with an Active Directory Server and likely
tomcat-users.xml as well).
In one of our projects, we authenticate users against the customer's
Active Directory Server. The sAMAccountName attribute is used as the
user's logon name. That's what the principal returns in its getName()
method. For example, we output that name in the footer of printed
reports. On reports created by me, 'c.klein' is shown.
In the ADS, my user class also has these attributes: (among many others)
displayName: ext. Klein, Carsten
givenName: Carsten
name: ext. Klein, Carsten
sn: Klein
(ext. = I'm an external user)
So, in order to show a more user-friendly name on the reports, I'd
configure the extraAttributes list to contain attribute 'displayName'.
Since our reports are template driven, I could as well retrieve fields
'givenNamen' and 'sn' and build my on report specific display name like
'${givenName} ${sn}' (with the knowledge in mind, that it's a German
customer and names in Germany typically are written that way).
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.
I guess, we will never find a bunch of attributes everybody can agree
with in all countries, companies and projects. So, there will likely
never be a mechanism that provides extra user attributes voluntarily.
But that was never announced. Some minimal and simple configuration is
still required.
For the same reason these attributes cannot be provided under arbitrary
names. But we could simply use the configured field names (which must be
the actual field names):
Config:
extraAttributes="displayName, givenName, sn"
Code: (no safe type checks here)
Principal p = ((TomcatPrincipal) request.getUserPrincipal());
out.writeln(p.getAttribute("displayName"));
It's not about saving a single database request per log in (at least not
from a performance point of view, technically, the request must be made
anyway).
But, it's about a simple, safe and reproducible way to get additional
fields from the user's record in the user database by just specifying
field names in a simple list. This can be done (and later changed) by
configuration only. No class has to be written. No extra configuration
for accessing the user database must be provided. No knowledge of SQL or
LDAP queries is required.
That's what this proposal offers: generic configurable retrieval of
extra attributes from the user's record in the user database. Nothing
more and nothing less. There's no room for an Extrawurst. If someone
want's "only a little bit more", he's free to leave the Relam's
attribute 'extraAttributes' empty and run his own mechanism.
Finally, I don't think that implementing this requires too much work (I
don't see the beast in it nor do I see a huge framework). If we stick to
the above offering, it's only about some additions to the Realm classes,
the TomcatPrincipal interface (optionally) and the GenericPrincipal class.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
