Am 2022-02-11 um 11:16 schrieb Rémy Maucherat:
On Fri, Feb 11, 2022 at 10:47 AM Michael Osipov <micha...@apache.org> wrote:
I cannot share your further explanations as well. The Realm *is* already
an object store. Principal name and roles are attributes on that object,
so is password. Without this possibility you have the following problems:
That statement is just weird. The realm stores credentials associated
with a principal name, as well as a list of roles (other names)
associated with that name. That's it. An object store can store
objects (like if there is a get/setAttribute that deals with Object -
and that's my problem now, as it turns out ...).
No, the realm stores the principal and can additionally store
crdentials. You have at least two mechanism which do not verify
credentials: SPNEGO and TLS mutual auth. I use both, authentication is
completely decoupled from the Realm. Does this onw disqualify? The realm
is always a read-only view on a store. Tomcat's intention is not to
provide any read/write interface to that store. Strictly reading only.
* You cannot abstract from the persistence layer in your application
code, at worst you need to double code for retrieval
* You double access time since you need to query the principal store
again. A performance penalty in a stateless application, e.g. APIs
* You maybe even not have access to the realm. Consider the identity
provider gives you some form of token containing the attributes which
you CANNOT retreive yourself. How to solve? You can't.
I don't believe the penalty exists for a DataSource backend. Most
likely for LDAP. Either way, the application is now non portable.
Given that the benefit for DataSource does not seem large, this simply
sounds bad in that case. For LDAP, it sounds like a tradeoff.
I disagree here also. Two options:
* The Realm database is decoupled form the app database, the app shall
not have access to it. What now?
* Consider the database is not in the same rack as the app server is. I
have cases where it is 500 km away, you instantly feel that the
roundtrip matters.
Sometimes you simply don't have control over the environment.
Yet another example: I have written code to locate the closest domain
controller, if I connect to that one I have response times < 10 ms, if I
connect to a DC in Munich, I suddenly have > 100 ms. Scale here.
No one is aiming here for an ORM layer.
One of my points is that this is really far from obvious in the API,
so it needs a round of javadoc tightening up.
Please do so.
M
