Re: Re: [tomcat] branch main updated: Add support for additional user, attributes in TomcatPrincipal

[Michael Osipov <mi...@apache.org>]

Rémy,

really, I don't understand your work attitude. Carsten contacted us on 
the mailing list before providing the PR. Then he provided the PR. It 
was open for EIGHT months. We discussed this in and out, with you and 
Mark. Everyone expressed the conditions he is willing to accept the PR. 
I have even asked Carsten to break up the PR to please you. The purpose 
of RTC/PR is to express your opinion BEFORE it gets merged to avoid 
post-mortem discussions like this. You expressed your conditions and now 
you object? This is absolutely not fair and unprofessional.

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:
* 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.

No one is aiming here for an ORM layer.


Mark,

you have even assisted on how to backport to previous versions and 
object somewhat as well? I don't understand that.


 From my PoV Carsten did everything we requested over a very long period 
of time.

M

Re: [tomcat] branch main updated: Add support for additional user, attributes in TomcatPrincipal

[Michael Osipov <mi...@apache.org>]

Am 2022-02-11 um 11:16 schrieb Rémy Maucherat:
> On Fri, Feb 11, 2022 at 10:47 AM Michael Osipov <mi...@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

Re: Re: [tomcat] branch main updated: Add support for additional user, attributes in TomcatPrincipal

[Rémy Maucherat <re...@apache.org>]

On Fri, Feb 11, 2022 at 10:47 AM Michael Osipov <mi...@apache.org> wrote:
>
> Rémy,
>
> really, I don't understand your work attitude. Carsten contacted us on
> the mailing list before providing the PR. Then he provided the PR. It
> was open for EIGHT months. We discussed this in and out, with you and
> Mark. Everyone expressed the conditions he is willing to accept the PR.
> I have even asked Carsten to break up the PR to please you. The purpose
> of RTC/PR is to express your opinion BEFORE it gets merged to avoid
> post-mortem discussions like this. You expressed your conditions and now
> you object? This is absolutely not fair and unprofessional.

I apologized for this already. I am really sorry about this but
background thinking led to different conclusions over time.

> 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 ...).

> * 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.

> 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.

Rémy

>
>
> Mark,
>
> you have even assisted on how to backport to previous versions and
> object somewhat as well? I don't understand that.
>
>
>  From my PoV Carsten did everything we requested over a very long period
> of time.
>
> M

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org