Re: Enhancement: Additional user attributes queried by (some) realms

[Carsten Klein]

Chris, Mark,

On 27/05/2021 22:11, Christopher Schultz wrote:





What's the primary use-case for these kinds of attributes?


This has been described in detail here:

http://mail-archives.apache.org/mod_mbox/tomcat-users/202104.mbox/ajax/%3Cb9a2a913-f00f-f5bf-ca05-8ea4f8663ca9%40datagis.com%3E

Trying brief:

Basically, it is about getting some user-friendly user related 
attributes, like display name, department, phone nuber, Email address 
into our applications. Typically, such attributes live in the same user 
database, that has already been configured for the Realm for 
authentication and authorization. That database might be an SQL database 
(DataSourceRealm) or any directory server (JNDIRealm).


Those attributes are often intended for display only (which user is 
logged on?). Another common case is sending mails from an application, 
which requires a valid From: address of the logged on user.


The Realm will have a new configuration option, e. g. 
additionalAttributes, which takes a comma separated field (attribute) 
list. The Realm, which already knows how to access that user database, 
is the responsible for querying that attributes from the "user table" in 
that database (e. g. in JNDI, that is the User's DirContext).


Without knowing anything about SQL or JNDI/LDAP queries, users can 
simply configure, what additional user attributes they like to get.


Without that, users need to implement a "session initialized"-hook and 
access that user database "manually" and need some knowledge of that 
database. Also, credentials for accessing that database must be provided 
separately for that hook method.



Unfortunately, Clonable and Serializable have both fallen out of favor 
in the Java world because both ideas seem to have some serious issues. 
If we pick one versus the other, we may have a lot of push-back.


Too bad. In order to get it bullet proof, my idea is to have a real deep 
copy cloning mechanism in Java. That may be even quite slow, since we 
could check for a couple of simple but fast cases up front (e. g. 
objects that are by design immutable, like String, or some other 
commonly used objects, for which we can provide a fast clone with a copy 
constructor).


Most of the attributes will likely be strings or be of any of the 
commonly used types so, only few object must go through the slow deep 
copy clone mechanism.


Actually, my idea was to use Serializable for that. What's the point 
with Serializable? Isn't Tomcat using that for clustering/HA as well? 
The documentation of Serializable is quite promising...




If we restrict attribute values to Strings, is that too limiting?


I consider that a last resort option, only. Maybe we could agree on 
String plus a limited number of well-known, commonly used and (by 
design) immutable objects like Number, Boolean, Date (is Date actually 
immutable?).


If we return Collections.unmodifiableMap() to return Map 
that makes things simpler. But how much do we trust 
Collections.unmodifiableMap if the underlying data are 
security-sensitive? With reflection, is it possible to monkey your way 
through the references and swap-out the underlying references? That 
might be Bad.


Reflection was another idea. This my slow down things noticeably but, if 
we have enough well-known fast-cloning object types defined, that should 
not be too bad.


On npm there are likely ten thousands of packages that support deep 
copying JavaScript objects. Where's the jpm for Java? Just kidding...


However, the deep copy problem should have been solved already, likely 
many many times. Isn't there a common utility function available for 
Java somewhere on the Internet? What about Apache Commons? Can we use 
these in Tomcat?


Carsten

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] web app big memory usage?

[Mysore, Raghunath]

You could try using the Oracle utility - "jstat"  - for analyzing the GC in an 
active Java process (PID) 
The "gcold" option helps us to peep into the Old Generation area 
jstat -gcold PID 
jstat -gcoldcapacity PID  

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html

-Original Message-
From: Berneburg, Cris J. - US  
Sent: Thursday, May 27, 2021 1:24 PM
To: users@tomcat.apache.org
Subject: [OT] web app big memory usage?

Hi Folks  :-)

One of our web apps is using a "lot" of memory, specifically a big user query.  
We'd like to find out why.

The Tomcat Web Application Manager Find leaks button said that "No web 
applications appear to have triggered a memory leak on stop, reload or 
undeploy."

Tomcat Manager Server Status shows that 1.7GB (82%) of G1 Old Gen space is 
being used that has not been recycled yet.

I grabbed a heap dump and used Eclipse Memory Analyzer, and it shows that only 
94MB of memory is being used when G1 Old Gen space used 1.8GB.  MAT seems to be 
looking only at the active objects, not the discarded ones.  IOW, we're looking 
at what the app is doing ATM, not what it already did.

I want to explore the 1.7GB garbage pile to see what's being thrown away, not 
what things are still being used, to determine wastefulness.

1. Is there a way to analyze uncollected garbage?

2. Is that a reasonable way to identify potential memory usage problems?

Some technical specifics:
* TC 8.5.63
* Java 1.8.0_291
* AWS EC2 instance.
* Windows Server 2016.
* Instance started as Windows Service.
* There are other TC instances on the same server.
* Each TC instance has multiple apps.

Thanks for reading this far.  :-)

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

-
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

Re: [OT] web app big memory usage?

[Christopher Schultz]

Cris,

On 5/27/21 15:24, Berneburg, Cris J. - US wrote:

Hi Folks  :-)

One of our web apps is using a "lot" of memory, specifically a big
user query.  We'd like to find out why.

The Tomcat Web Application Manager Find leaks button said that "No
web applications appear to have triggered a memory leak on stop,
reload or undeploy."

Tomcat Manager Server Status shows that 1.7GB (82%) of G1 Old Gen
space is being used that has not been recycled yet.

I grabbed a heap dump and used Eclipse Memory Analyzer, and it shows
that only 94MB of memory is being used when G1 Old Gen space used
1.8GB.  MAT seems to be looking only at the active objects, not the
discarded ones.  IOW, we're looking at what the app is doing ATM, not
what it already did.

I want to explore the 1.7GB garbage pile to see what's being thrown
away, not what things are still being used, to determine
wastefulness.

1. Is there a way to analyze uncollected garbage?

2. Is that a reasonable way to identify potential memory usage
problems?

Some technical specifics: * TC 8.5.63 * Java 1.8.0_291 * AWS EC2
instance. * Windows Server 2016. * Instance started as Windows
Service. * There are other TC instances on the same server. * Each TC
instance has multiple apps.

Thanks for reading this far.  :-)


What's the goal? Do you just Want To Know, or are you trying to solve an
actual problem.

If you have a bunch of garbage that's not being cleaned up, usually it's
because there is simply no need to do so. The GC is behaving according
to the 3 laws of rob..., er, 3 virtues of computing[1]:

  1. Laziness: nothing needs that memory so... meh
  2. Impatience: gotta clean that Eden space quick
  3. Hubris: if I ever need more memory, I know where to find it

Seriously, though, the only real difference between the new gen and the 
old gen is time, so if your query ran faster it might get a lot more of 
its scratch objects cleaner-up without having to ask for a full GC.


How long does the query take to run? What kind of query is it? Are we 
talking about something like SQL or some in-memory database or something 
which really does take a lot of memory for the application to fulfill 
the request?


[1] http://threevirtues.com/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: Additional user attributes queried by (some) realms

[Christopher Schultz]

Mark,

On 5/27/21 12:22, Mark Thomas wrote:

On 27/05/2021 15:04, Christopher Schultz wrote:

Mark,

On 5/27/21 04:59, Mark Thomas wrote:

On 27/05/2021 07:32, Carsten Klein wrote:

On 26/05/2021 19:56, Mark Thomas wrote:

Given that the attributes may well be security related, you would 
need to make sure neither the Map nor any of the keys/values could 
be modified. Protecting the Map is easy. Protecting the keys/values 
is a little trickier. For that reason I'd lean towards the solution 
below.


Oh yes, these attributes should likely be immutable. Since I still 
believe that Enumerations are kind of uncomfortable (and outdated?), 
what about strictly relying on Collections.unmodifiableMap?


The issue while objects can't be added to the Map or removed from the 
Map, the objects can still be mutated. For that reason I prefer the 
getAttribute() approach where an appropriate defensive copy can be 
made before returning any attribute value.


Does that mean this needs to be Map>? Or 
Map>?


How do you expect to perform defensive-copies of arbitrary objects?


Good point. I think that means attribute values can't be any old object. 
Limiting things to  seems reasonable to me as that 
makes the defensive copy easy. Although that does lead to a deep clone 
vs shallow cone discussion. I think the simplest way to deal with that 
is to document how the defensive copy is made and note that users of the 
API need to be sure any attributes they provide are safe given how the 
defensive copy is made.


Unfortunately, Clonable and Serializable have both fallen out of favor 
in the Java world because both ideas seem to have some serious issues. 
If we pick one versus the other, we may have a lot of push-back.


What's the primary use-case for these kinds of attributes?

If we restrict attribute values to Strings, is that too limiting?

If we return Collections.unmodifiableMap() to return Map 
that makes things simpler. But how much do we trust 
Collections.unmodifiableMap if the underlying data are 
security-sensitive? With reflection, is it possible to monkey your way 
through the references and swap-out the underlying references? That 
might be Bad.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] web app big memory usage?

[John.E.Gregg]

Cris,


> -Original Message-
> From: Berneburg, Cris J. - US 
> Sent: Thursday, May 27, 2021 2:24 PM
> To: users@tomcat.apache.org
> Subject: [OT] web app big memory usage?
> 
> Hi Folks  :-)
> 
> One of our web apps is using a "lot" of memory, specifically a big user query.
> We'd like to find out why.
> 
> The Tomcat Web Application Manager Find leaks button said that "No web
> applications appear to have triggered a memory leak on stop, reload or
> undeploy."
> 
> Tomcat Manager Server Status shows that 1.7GB (82%) of G1 Old Gen space
> is being used that has not been recycled yet.
> 
> I grabbed a heap dump and used Eclipse Memory Analyzer, and it shows that
> only 94MB of memory is being used when G1 Old Gen space used 1.8GB.
> MAT seems to be looking only at the active objects, not the discarded ones.
> IOW, we're looking at what the app is doing ATM, not what it already did.
> 
> I want to explore the 1.7GB garbage pile to see what's being thrown away,
> not what things are still being used, to determine wastefulness.
> 
> 1. Is there a way to analyze uncollected garbage?
> 
> 2. Is that a reasonable way to identify potential memory usage problems?
> 
> Some technical specifics:
> * TC 8.5.63
> * Java 1.8.0_291
> * AWS EC2 instance.
> * Windows Server 2016.
> * Instance started as Windows Service.
> * There are other TC instances on the same server.
> * Each TC instance has multiple apps.
> 
> Thanks for reading this far.  :-)
> 
> --
> Cris Berneburg
> CACI Senior Software Engineer
> 
> 
> 
> 
> This electronic message contains information from CACI International Inc or
> subsidiary companies, which may be company sensitive, proprietary,
> privileged or otherwise protected from disclosure. The information is
> intended to be used solely by the recipient(s) named above. If you are not
> an intended recipient, be aware that any review, disclosure, copying,
> distribution or use of this transmission or its contents is prohibited. If you
> have received this transmission in error, please notify the sender
> immediately.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

MAT has an option  to "Keep unreachable options."  It's under preferences.

It sounds like you don't have an actual leak, just high allocation/GC.  My 
favorite tool for this is to use the Java Flight Recorder and analyze it with 
Java Mission Control.

John


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] web app big memory usage?

[Amit Pande]

Have you enabled the " Enable 'keep unreachable objects'" setting of MAT?

https://blog.gceasy.io/2015/12/11/eclipse-mat-titbits/


Thanks,
Amit

-Original Message-
From: Berneburg, Cris J. - US  
Sent: Thursday, May 27, 2021 2:24 PM
To: users@tomcat.apache.org
Subject: [EXTERNAL] [OT] web app big memory usage?

Hi Folks  :-)

One of our web apps is using a "lot" of memory, specifically a big user query.  
We'd like to find out why.

The Tomcat Web Application Manager Find leaks button said that "No web 
applications appear to have triggered a memory leak on stop, reload or 
undeploy."

Tomcat Manager Server Status shows that 1.7GB (82%) of G1 Old Gen space is 
being used that has not been recycled yet.

I grabbed a heap dump and used Eclipse Memory Analyzer, and it shows that only 
94MB of memory is being used when G1 Old Gen space used 1.8GB.  MAT seems to be 
looking only at the active objects, not the discarded ones.  IOW, we're looking 
at what the app is doing ATM, not what it already did.

I want to explore the 1.7GB garbage pile to see what's being thrown away, not 
what things are still being used, to determine wastefulness.

1. Is there a way to analyze uncollected garbage?

2. Is that a reasonable way to identify potential memory usage problems?

Some technical specifics:
* TC 8.5.63
* Java 1.8.0_291
* AWS EC2 instance.
* Windows Server 2016.
* Instance started as Windows Service.
* There are other TC instances on the same server.
* Each TC instance has multiple apps.

Thanks for reading this far.  :-)

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

-
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

[OT] web app big memory usage?

[Berneburg, Cris J. - US]

Hi Folks  :-)

One of our web apps is using a "lot" of memory, specifically a big user query.  
We'd like to find out why.

The Tomcat Web Application Manager Find leaks button said that "No web 
applications appear to have triggered a memory leak on stop, reload or 
undeploy."

Tomcat Manager Server Status shows that 1.7GB (82%) of G1 Old Gen space is 
being used that has not been recycled yet.

I grabbed a heap dump and used Eclipse Memory Analyzer, and it shows that only 
94MB of memory is being used when G1 Old Gen space used 1.8GB.  MAT seems to be 
looking only at the active objects, not the discarded ones.  IOW, we're looking 
at what the app is doing ATM, not what it already did.

I want to explore the 1.7GB garbage pile to see what's being thrown away, not 
what things are still being used, to determine wastefulness.

1. Is there a way to analyze uncollected garbage?

2. Is that a reasonable way to identify potential memory usage problems?

Some technical specifics:
* TC 8.5.63
* Java 1.8.0_291
* AWS EC2 instance.
* Windows Server 2016.
* Instance started as Windows Service.
* There are other TC instances on the same server.
* Each TC instance has multiple apps.

Thanks for reading this far.  :-)

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: Additional user attributes queried by (some) realms

[Michael Osipov]

You read my mind. I always wanted to report this, but never find time. 
Implemented this for our realm and principal years ago:

http://tomcatspnegoad.sourceforge.net/apidocs/net/sf/michaelo/tomcat/realm/ActiveDirectoryPrincipal.html#getAdditionalAttributes--

The entire principal should be immutable, thus return only read-only 
objects. Always.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: Additional user attributes queried by (some) realms

[Carsten Klein]

Mark,

On 27/05/2021 18:19, Mark Thomas wrote:

I will note that it isn't uncommon to have to log out and back in again 
to pick up newly allocated groups/roles in other environments.


Yes, you are right. Didn't see it that way so far. We're talking about 
live updates for a session during its lifetime, which we can surely 
drop. Only few other Realms will support this (if any).


If we go the removal route then I'd treat that as a separate PR / 
bugzilla issue so any discussion remains focussed on the relevant issue.


The removal route seems simple. Both the UserDatabasePrincipal and the 
hasRole()-overwrite can be removed. That should do the trick.


I will provide a PR and file a corresponding issue in Bugzilla soon.

Carsten

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat SSL stops working after an undetermined amount of time

[Mysore, Raghunath]

Hi Ezsra, 
 I concur with suggestions from  Chris Schultz.  
Would you clarify the following items ?
The current focus is to understand the prevailing environment configuration, in 
context of the stack trace you shared earlier. 

(1) To go back,  did you check  for ".jar"  files with names like "bouncy" ? 
The point here is - to understand where BC is configured (to assess if it can 
be commented)
(2) Apart from considering to turnoff BC,  have you tried disabling RSASSA-PSS 
algorithm ? 
(3) When you test using a Safari browser - is the application on a happy path 
(meaning SSL works all fine) ?  
And you have the issue only when testing from a  Chrome browser ? 

Thanks,
 -Raghu 

-Original Message-
From: Ezsra McDonald  
Sent: Thursday, May 27, 2021 8:56 AM
To: Tomcat Users List 
Subject: Re: Tomcat SSL stops working after an undetermined amount of time

Thanks for the responses,

So, I need to understand a little more about Bouncycastle. I inherited the 
tomcat environment so I do not know how or why BC came to be installed in the 
containers. I will do some research on BC so I understand it better. My 
assumption from the responses is that BC is not a standard part of Tomcat or 
Java install.

If the BC is part of an application running in the container and comes from a 
war file, can it be causing this issue? Or is BC most likely loaded when the 
container starts?

--Ez

On Thu, May 27, 2021 at 8:37 AM Christopher Schultz < 
ch...@christopherschultz.net> wrote:

> Raghunath,
>
> On 5/26/21 19:08, Mysore, Raghunath wrote:
> > To track if BC is configured in your environment, you may want to 
> > assess if BC is listed as a "security.provider"  in the following 
> > "java.security" file
> >
> >
> >
> > File :  /jre/lib/security/java.security
> >
> > Check for record (example below) :
> >
> > security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvi
> > der
> >
> >
> >
> >
> > Note the Number 10, above may be something different in your 
> > environment's "java.security" file (presuming BC is configured here)
>
> Well, the error being encountered is definite within BC, so I'd 
> venture a guess that BC is indeed being used.
>
> -chris
>
> > -Original Message- From: Christopher Schultz 
> >  Sent: Wednesday, May 26, 2021 4:35 PM
> > To: users@tomcat.apache.org Subject: Re: Tomcat SSL stops working 
> > after an undetermined amount of time
> >
> >
> >
> > Ezsra,
> >
> >
> >
> > On 5/26/21 18:11, Ezsra McDonald wrote:
> >
> >> Well, I still have issues. I think it is the same thing hit by 
> >> these guys:
> >
> >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fj
> >> ira
> >
> >>
> >> .atlassian.com%2Fbrowse%2FBAM-21157data=04%7C01%7Crmysore%40visa.
> >
> >>
> >> com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee888b9c4db1c
> >> 477
> >
> >>
> >> d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >> 4wL
> >
> >>
> >> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sd
> >> ata
> >
> >>
> >> =QnzOhDNvEy%2FVBRmUz0B2F0iqOlH9gpBUJBwqNzHwz%2F4%3Dreserved=0
> >
> >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs
> >> tac
> >
> >>
> >> koverflow.com%2Fquestions%2F65691480%2Fnullpointerexception-at-org-
> >> bou
> >
> >>
> >> ncycastle-crypto-signers-psssigner-generatesignatdata=04%7C01%
> >> 7Cr
> >
> >>
> >> mysore%40visa.com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d
> >> 4ee
> >
> >>
> >> 888b9c4db1c477d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZs
> >> b3d
> >
> >>
> >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> >> %7C
> >
> >>
> >> 1000sdata=PtS%2BltOexMX3CmAFTFc11Gt%2B57LoHvUgPu2k0nxJQ2M%3D
> >> mp;
> >
> >>  reserved=0
> >
> >>
> >
> >> I'll try their fix. My main concern is that I do not want to 
> >> disable
> >
> >> TLSv1.3.
> >
> >
> >
> > If you don't want to disable TLSv1.3, then you want:
> >
> >
> >
> >  >
> > protocols="TLSv1.2,TLSv1.3"
> >
> > />
> >
> >
> >
> > If BC is failing you, I'd want to find out if you really need BC.
> >
> >
> >
> > That first link above seems to suggest that when using Tomcat you 
> > MUST disable TLSv1.3. That seems odd. What version of BC are you 
> > using?
> >
> > Search for .jar files with names like "bouncy".
> >
> >
> >
> > Do you have the option to downgrade Java?
> >
> >
> >
> > Have you tried disabling the RSASSA-PSS algorithm as per their 
> > instructions? It seems ... far-fetched that would fix the problem, 
> > but ... okay.
> >
> >
> >
> > Note that at some time in the past, Java 1.8 did not support TLSv1.3 
> > and lots of people who were stuck on Java 1.8 decided to switch to 
> > BC which did have TLSv1.3 support. With that version of Java 1.8 
> > (_281), you should have native JDK support for TLSv1.3. Perhaps BC 
> > is not necessary at all.
> >
> >
> >
> > -chris
> >
> >
> >
> >> On Tue, May 25, 2021 at 11:09 AM Ezsra McDonald
> >
> >> mailto:ezsra.mcdon...@gmail.com>>
> >
> >> wrote:

Re: Enhancement: Additional user attributes queried by (some) realms

[Mark Thomas]

On 27/05/2021 15:04, Christopher Schultz wrote:

Mark,

On 5/27/21 04:59, Mark Thomas wrote:

On 27/05/2021 07:32, Carsten Klein wrote:

On 26/05/2021 19:56, Mark Thomas wrote:

Given that the attributes may well be security related, you would 
need to make sure neither the Map nor any of the keys/values could 
be modified. Protecting the Map is easy. Protecting the keys/values 
is a little trickier. For that reason I'd lean towards the solution 
below.


Oh yes, these attributes should likely be immutable. Since I still 
believe that Enumerations are kind of uncomfortable (and outdated?), 
what about strictly relying on Collections.unmodifiableMap?


The issue while objects can't be added to the Map or removed from the 
Map, the objects can still be mutated. For that reason I prefer the 
getAttribute() approach where an appropriate defensive copy can be 
made before returning any attribute value.


Does that mean this needs to be Map>? Or 
Map>?


How do you expect to perform defensive-copies of arbitrary objects?


Good point. I think that means attribute values can't be any old object. 
Limiting things to  seems reasonable to me as that 
makes the defensive copy easy. Although that does lead to a deep clone 
vs shallow cone discussion. I think the simplest way to deal with that 
is to document how the defensive copy is made and note that users of the 
API need to be sure any attributes they provide are safe given how the 
defensive copy is made.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: Additional user attributes queried by (some) realms

[Mark Thomas]

On 27/05/2021 12:49, Carsten Klein wrote:

On 27/05/2021 10:59, Mark Thomas wrote:



As far as I can tell, removing UserDatabasePrincipal, relying on 
GenericPrincipal and User remaining an internal object not exposed via 
the Servlet API would achieve the same result with less code.


At this point I am looking for a reason not to remove 
UserDatabasePrincipal and I'm not seeing one.


Since User and Role instances support dynamic updates (have a look at 
methods addGroup/Role and removeGroup/Role), the special handling in 
UserDatabaseRealm.hasRole() is required. Although that feature is 
currently not used by Tomcat (is it?), those possible live updates must 
be taken into account in the code.


You can just as easily add roles in a database for the DataSourceRealm 
or in LDAP for the JNDIRealm and we don't handle the dynamic update case 
for either of those. I don't have a strong view of whether we should 
handle this or shouldn't but I do have a strong view that we should try 
to be consistent.


I will note that it isn't uncommon to have to log out and back in again 
to pick up newly allocated groups/roles in other environments.




I think it would be worth handling this is a separate commit to give 
folks the chance to review it before proceeding to add attribute support.


+1

Are you talking about a separate commit in my additional-user-attributes 
branch? Or is that worth an extra BUG/case/issue?


If we go the removal route then I'd treat that as a separate PR / 
bugzilla issue so any discussion remains focussed on the relevant issue.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat SSL stops working after an undetermined amount of time

[Ezsra McDonald]

Thanks for the responses,

So, I need to understand a little more about Bouncycastle. I inherited the
tomcat environment so I do not know how or why BC came to be installed in
the containers. I will do some research on BC so I understand it better. My
assumption from the responses is that BC is not a standard part of Tomcat
or Java install.

If the BC is part of an application running in the container and comes from
a war file, can it be causing this issue? Or is BC most likely loaded when
the container starts?

--Ez

On Thu, May 27, 2021 at 8:37 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Raghunath,
>
> On 5/26/21 19:08, Mysore, Raghunath wrote:
> > To track if BC is configured in your environment, you may want to
> > assess if BC is listed as a "security.provider"  in the following
> > "java.security" file
> >
> >
> >
> > File :  /jre/lib/security/java.security
> >
> > Check for record (example below) :
> >
> > security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider
> >
> >
> >
> >
> > Note the Number 10, above may be something different in your
> > environment's "java.security" file (presuming BC is configured here)
>
> Well, the error being encountered is definite within BC, so I'd venture
> a guess that BC is indeed being used.
>
> -chris
>
> > -Original Message- From: Christopher Schultz
> >  Sent: Wednesday, May 26, 2021 4:35 PM
> > To: users@tomcat.apache.org Subject: Re: Tomcat SSL stops working
> > after an undetermined amount of time
> >
> >
> >
> > Ezsra,
> >
> >
> >
> > On 5/26/21 18:11, Ezsra McDonald wrote:
> >
> >> Well, I still have issues. I think it is the same thing hit by
> >> these guys:
> >
> >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira
> >
> >>
> >> .atlassian.com%2Fbrowse%2FBAM-21157data=04%7C01%7Crmysore%40visa.
> >
> >>
> >> com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee888b9c4db1c477
> >
> >>
> >> d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> >
> >>
> >> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata
> >
> >>
> >> =QnzOhDNvEy%2FVBRmUz0B2F0iqOlH9gpBUJBwqNzHwz%2F4%3Dreserved=0
> >
> >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstac
> >
> >>
> >> koverflow.com%2Fquestions%2F65691480%2Fnullpointerexception-at-org-bou
> >
> >>
> >> ncycastle-crypto-signers-psssigner-generatesignatdata=04%7C01%7Cr
> >
> >>
> >> mysore%40visa.com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee
> >
> >>
> >> 888b9c4db1c477d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d
> >
> >>
> >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> >
> >>
> >> 1000sdata=PtS%2BltOexMX3CmAFTFc11Gt%2B57LoHvUgPu2k0nxJQ2M%3D
> >
> >>  reserved=0
> >
> >>
> >
> >> I'll try their fix. My main concern is that I do not want to
> >> disable
> >
> >> TLSv1.3.
> >
> >
> >
> > If you don't want to disable TLSv1.3, then you want:
> >
> >
> >
> >  >
> > protocols="TLSv1.2,TLSv1.3"
> >
> > />
> >
> >
> >
> > If BC is failing you, I'd want to find out if you really need BC.
> >
> >
> >
> > That first link above seems to suggest that when using Tomcat you
> > MUST disable TLSv1.3. That seems odd. What version of BC are you
> > using?
> >
> > Search for .jar files with names like "bouncy".
> >
> >
> >
> > Do you have the option to downgrade Java?
> >
> >
> >
> > Have you tried disabling the RSASSA-PSS algorithm as per their
> > instructions? It seems ... far-fetched that would fix the problem,
> > but ... okay.
> >
> >
> >
> > Note that at some time in the past, Java 1.8 did not support TLSv1.3
> > and lots of people who were stuck on Java 1.8 decided to switch to BC
> > which did have TLSv1.3 support. With that version of Java 1.8 (_281),
> > you should have native JDK support for TLSv1.3. Perhaps BC is not
> > necessary at all.
> >
> >
> >
> > -chris
> >
> >
> >
> >> On Tue, May 25, 2021 at 11:09 AM Ezsra McDonald
> >
> >> mailto:ezsra.mcdon...@gmail.com>>
> >
> >> wrote:
> >
> >>
> >
> >>> Lots of good information was provided.
> >
> >>>
> >
> >>> This afternoon I plan to test the "sslProtocol"  to "protocols"
> >
> >>> change in our lower environments. I will reply back with any
> >>> findings.
> >
> >>>
> >
> >>> Thank you everyone for your responses.
> >
> >>>
> >
> >>> regards,
> >
> >>>
> >
> >>> -- Ez
> >
> >>>
> >
> >>> On Tue, May 25, 2021 at 10:48 AM Mysore, Raghunath
> >
> >>> mailto:rmys...@visa.com.invalid>>
> >>> wrote:
> >
> >>>
> >
>  Hi Chris,
> >
> 
> >
>  -Original Message-
> >
>  From: Christopher Schultz
>  mailto:ch...@christopherschultz.net>>
> >
>   Sent: Tuesday, May 25, 2021 9:10 AM
> >
>  To: users@tomcat.apache.org
> >
>  Subject: Re: Tomcat SSL stops working after an undetermined
>  amount
> >
>  of time
> >
> 
> >
>  Ronald,
> >
> 
> >
>  On 5/25/21 09:31, Roskens, Ronald wrote:
> >
> >
> >
> >> -Original 

Re: Enhancement: Additional user attributes queried by (some) realms

[Christopher Schultz]

Mark,

On 5/27/21 04:59, Mark Thomas wrote:

On 27/05/2021 07:32, Carsten Klein wrote:

On 26/05/2021 19:56, Mark Thomas wrote:

Given that the attributes may well be security related, you would 
need to make sure neither the Map nor any of the keys/values could be 
modified. Protecting the Map is easy. Protecting the keys/values is a 
little trickier. For that reason I'd lean towards the solution below.


Oh yes, these attributes should likely be immutable. Since I still 
believe that Enumerations are kind of uncomfortable (and outdated?), 
what about strictly relying on Collections.unmodifiableMap?


The issue while objects can't be added to the Map or removed from the 
Map, the objects can still be mutated. For that reason I prefer the 
getAttribute() approach where an appropriate defensive copy can be made 
before returning any attribute value.


Does that mean this needs to be Map>? Or 
Map>?


How do you expect to perform defensive-copies of arbitrary objects?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat SSL stops working after an undetermined amount of time

[Christopher Schultz]

Raghunath,

On 5/26/21 19:08, Mysore, Raghunath wrote:

To track if BC is configured in your environment, you may want to
assess if BC is listed as a "security.provider"  in the following
"java.security" file



File :  /jre/lib/security/java.security

Check for record (example below) :

security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider




Note the Number 10, above may be something different in your
environment's "java.security" file (presuming BC is configured here)


Well, the error being encountered is definite within BC, so I'd venture
a guess that BC is indeed being used.

-chris


-Original Message- From: Christopher Schultz
 Sent: Wednesday, May 26, 2021 4:35 PM 
To: users@tomcat.apache.org Subject: Re: Tomcat SSL stops working

after an undetermined amount of time



Ezsra,



On 5/26/21 18:11, Ezsra McDonald wrote:


Well, I still have issues. I think it is the same thing hit by
these guys:



https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira


 
.atlassian.com%2Fbrowse%2FBAM-21157data=04%7C01%7Crmysore%40visa.


 
com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee888b9c4db1c477


 
d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL


 
jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata


 
=QnzOhDNvEy%2FVBRmUz0B2F0iqOlH9gpBUJBwqNzHwz%2F4%3Dreserved=0



https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstac


 
koverflow.com%2Fquestions%2F65691480%2Fnullpointerexception-at-org-bou


 
ncycastle-crypto-signers-psssigner-generatesignatdata=04%7C01%7Cr


 
mysore%40visa.com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee


 
888b9c4db1c477d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d


 
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C


 
1000sdata=PtS%2BltOexMX3CmAFTFc11Gt%2B57LoHvUgPu2k0nxJQ2M%3D



 reserved=0







I'll try their fix. My main concern is that I do not want to
disable



TLSv1.3.




If you don't want to disable TLSv1.3, then you want:







If BC is failing you, I'd want to find out if you really need BC.



That first link above seems to suggest that when using Tomcat you
MUST disable TLSv1.3. That seems odd. What version of BC are you
using?

Search for .jar files with names like "bouncy".



Do you have the option to downgrade Java?



Have you tried disabling the RSASSA-PSS algorithm as per their
instructions? It seems ... far-fetched that would fix the problem,
but ... okay.



Note that at some time in the past, Java 1.8 did not support TLSv1.3
and lots of people who were stuck on Java 1.8 decided to switch to BC
which did have TLSv1.3 support. With that version of Java 1.8 (_281),
you should have native JDK support for TLSv1.3. Perhaps BC is not
necessary at all.



-chris




On Tue, May 25, 2021 at 11:09 AM Ezsra McDonald



mailto:ezsra.mcdon...@gmail.com>>



wrote:







Lots of good information was provided.







This afternoon I plan to test the "sslProtocol"  to "protocols"



change in our lower environments. I will reply back with any
findings.







Thank you everyone for your responses.







regards,







-- Ez







On Tue, May 25, 2021 at 10:48 AM Mysore, Raghunath



mailto:rmys...@visa.com.invalid>>
wrote:







Hi Chris,







-Original Message-



From: Christopher Schultz
mailto:ch...@christopherschultz.net>>



 Sent: Tuesday, May 25, 2021 9:10 AM



To: users@tomcat.apache.org



Subject: Re: Tomcat SSL stops working after an undetermined
amount



of time







Ronald,







On 5/25/21 09:31, Roskens, Ronald wrote:







-Original Message-



From: Christopher Schultz
mailto:ch...@christopherschultz.net>>



 Sent: Monday, May 24, 2021 1:56 PM



To:
users@tomcat.apache.org



Subject: [EXTERNAL] Re: Tomcat SSL stops working after an



undetermined amount of time







CAUTION: This email originated from outside of the
organization.



DO NOT CLICK on links or open attachments unless you
recognize the



sender and know the content is safe.







Ezsra,







On 5/24/21 10:30, Ezsra McDonald wrote:



I am enabling SSL debugging this morning. I did catch
this in the



log for an instance that started erroring out this
morning. Seems



like it may be too generic to help solve my problem. Here
it is:







24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]



org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun



 java.lang.NullPointerException



at



org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unkno



 wn



Source)



at
org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown



 Source)







Oh. You are using BouncyCastle. I've never tried to do
that. I'm



not sure how well BC will work with Tomcat. We don't
officially



support that configuration, but that doesn't mean we won't
try to help.







This isn't a Tomcat issue but an interoperability issue

Re: Enhancement: Additional user attributes queried by (some) realms

[Carsten Klein]

On 27/05/2021 10:59, Mark Thomas wrote:



As far as I can tell, removing UserDatabasePrincipal, relying on 
GenericPrincipal and User remaining an internal object not exposed via 
the Servlet API would achieve the same result with less code.


At this point I am looking for a reason not to remove 
UserDatabasePrincipal and I'm not seeing one.


Since User and Role instances support dynamic updates (have a look at 
methods addGroup/Role and removeGroup/Role), the special handling in 
UserDatabaseRealm.hasRole() is required. Although that feature is 
currently not used by Tomcat (is it?), those possible live updates must 
be taken into account in the code.


If the UserDatabase was immutable, we could simply go ahead with the 
pre-resolved effective roles list and GenericPrincipal. But actually, 
those effective roles may be wrong after an update of the UserDatabase.


So, I suggest not resolving effective roles up front in 
UserDatabaseRealm.getPrincipal() and use null as the roles list when 
constructing the new GenericPrincipal instance.


The special handling in UserDatabaseRealm.hasRole() is triggered, if the 
Principal is a GenericPrincipal with a userPrincipal of type 
UserDatabasePrincipal:


if (principal instanceof GenericPrincipal) {
GenericPrincipal gp = (GenericPrincipal) principal;
if (gp.getUserPrincipal() instanceof UserDatabasePrincipal) {
principal = database.findUser(gp.getName());
}
}

The current test requires an extra UserDatabasePrincipal class. Making 
that class support attributes and serializable is possible.


However, a simple default/package visible boolean flag 
'userDatabasePrincipal' in GenericPrincipal would work as well and lets 
us finally drop class UserDatabasePrincipal.




I think it would be worth handling this is a separate commit to give 
folks the chance to review it before proceeding to add attribute support.


+1

Are you talking about a separate commit in my additional-user-attributes 
branch? Or is that worth an extra BUG/case/issue?




I suspect the users that worry about that sort of thing aren't using the 
UserDatabaseRealm but it would be nice to fix that anyway.


That will be fixed after having added attribute support either way.

Carsten

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: JNDI ldaps Problem with SSO

[Susan.Wood]

Hi Christopher

Enclosed is the stacktrace of the tomcat (localhost) 

03-Mar-2021 15:57:15.221 SEVERE [http-nio-8080-exec-10] 
org.apache.catalina.realm.JNDIRealm.authenticate Exception performing 
authentication
 javax.naming.NamingException: [LDAP: error code 1 - 04DC: LdapErr: 
DSID-0C0907E9, comment: In order to perform this operation a successful bind 
must be completed on the connection., data 0, v2580 ]; remaining name 
'DC=bcintra,DC=CH'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3299)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3205)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2996)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1875)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798)
at 
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
at 
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
at 
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)
at 
javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
at 
org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1655)
at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1491)
at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1439)
at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1380)
at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1267)
at 
org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:193)
at 
org.apache.catalina.authenticator.AuthenticatorBase.doLogin(AuthenticatorBase.java:950)
at 
org.apache.catalina.authenticator.AuthenticatorBase.login(AuthenticatorBase.java:932)
at org.apache.catalina.connector.Request.login(Request.java:2674)
at 
org.apache.catalina.connector.RequestFacade.login(RequestFacade.java:1072)
at 
javax.servlet.http.HttpServletRequestWrapper.login(HttpServletRequestWrapper.java:318)
at 
com.nm.exprlang.functions.LoginFunction.calculate(LoginFunction.java:41)
at 
com.nm.sdk.data.expeval.MethodCallUtils.callScriptFunction(MethodCallUtils.java:207)
at 
com.nm.sdk.data.expeval.nodes.FunctionNode.execute(FunctionNode.java:465)
at 
com.nm.sdk.data.expeval.MethodCallUtils.callScriptFunction(MethodCallUtils.java:153)
at 
com.nm.sdk.data.expeval.nodes.FunctionNode.execute(FunctionNode.java:465)
at 
com.nm.sdk.data.expeval.nodes.ScriptBodyNode.execute(ScriptBodyNode.java:176)
at com.nm.exprlang.InterpreterImpl.execute(InterpreterImpl.java:417)
at com.nm.exprlang.InterpreterImpl.interpret(InterpreterImpl.java:384)
at com.nm.exprlang.InterpreterImpl.interpret(InterpreterImpl.java:371)
at com.nm.exprlang.InterpreterImpl.interpret(InterpreterImpl.java:326)
at 
com.nm.sdk.data.pages.views.actions.ExpressionAction.execute(ExpressionAction.java:76)
at 
com.nm.sdk.data.pages.views.components.Component.handleEvent(Component.java:930)
at 
com.nm.sdk.data.pages.views.components.Component.handleEvents(Component.java:898)
at 
com.nm.sdk.data.pages.views.components.Component.process(Component.java:871)
at 
com.nm.sdk.data.pages.views.components.CustomControl.processComponent(CustomControl.java:295)
at 
com.nm.sdk.data.pages.views.components.Component.process(Component.java:872)
at 
com.nm.sdk.data.pages.views.components.Container.processChildren(Container.java:408)
at 
com.nm.sdk.data.pages.views.components.Container.processComponent(Container.java:403)
at 
com.nm.sdk.data.pages.views.components.Component.process(Component.java:872)
at 
com.nm.sdk.data.pages.views.components.Container.processChildren(Container.java:408)
at 
com.nm.sdk.data.pages.views.components.Container.processComponent(Container.java:403)
at 
com.nm.sdk.data.pages.views.components.Component.process(Component.java:872)
at 
com.nm.sdk.data.pages.views.components.Container.processChildren(Container.java:408)
at 
com.nm.sdk.data.pages.views.components.Container.processComponent(Container.java:403)
at 
com.nm.sdk.data.pages.views.components.Component.process(Component.java:872)
at 
com.nm.screenflow.PageServiceImpl.processPageResponse(PageServiceImpl.java:1450)
at 
com.nm.sdk.data.workflow.model.ScreenTask.processHttpRequest(ScreenTask.java:524)
at 
com.nm.workspace.ProcessServlet.processWorkflowToken(ProcessServlet.java:554)
at 
com.nm.workspace.ProcessServlet.processWorkitem(ProcessServlet.java:264)
at com.nm.workspace.ProcessServlet.doPost(ProcessServlet.java:134)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
at 

Re: Enhancement: Additional user attributes queried by (some) realms

[Mark Thomas]

On 27/05/2021 07:32, Carsten Klein wrote:

On 26/05/2021 19:56, Mark Thomas wrote:

Given that the attributes may well be security related, you would need 
to make sure neither the Map nor any of the keys/values could be 
modified. Protecting the Map is easy. Protecting the keys/values is a 
little trickier. For that reason I'd lean towards the solution below.


Oh yes, these attributes should likely be immutable. Since I still 
believe that Enumerations are kind of uncomfortable (and outdated?), 
what about strictly relying on Collections.unmodifiableMap?


The issue while objects can't be added to the Map or removed from the 
Map, the objects can still be mutated. For that reason I prefer the 
getAttribute() approach where an appropriate defensive copy can be made 
before returning any attribute value.


Since UserDatabasePrincipal is a private inner class of 
UserDatabaseRealm, no instanceof checks are possible to determine 
whether attributes may be available or not. So, I was thinking of a new 
interface


public interface AttributedPrincipal extends Principal {

   public Object getAttribute(String name);

   Enumeration getAttributeNames();

}

That interface has a slightly more meaningful name for consumers of 
additional user attributes. But adding these methods to TomcatPrincipal 
is good as well.


I don't see a need either now or in the future to differentiate between 
TomcatPrimcipal and AttributePrincipal. If we can think of a valid use 
case for separate interfaces I'd support that - but at the moment I 
don't see one.



3. Class UserDatabasePrincipal in UserDatabaseRealm




So, the only thing UserDatabasePrincipal does, is to hide the fact that 
groups have already been resolved to a single list of effective roles, 
the Principal is working with during its lifetime. Did I overlook 
something?


I don't think so.

I think I have figured it out.

User implements Principal and exposes various fields including password.

User was used as the UserPrincipal stored in GenericPrincipal

Some time ago, getPassword() was removed from GenericPrincipal. In order 
to prevent access to User.getPassword(), UserDatabasePrincipal was 
introduced.


As far as I can tell, removing UserDatabasePrincipal, relying on 
GenericPrincipal and User remaining an internal object not exposed via 
the Servlet API would achieve the same result with less code.


At this point I am looking for a reason not to remove 
UserDatabasePrincipal and I'm not seeing one.


I think it would be worth handling this is a separate commit to give 
folks the chance to review it before proceeding to add attribute support.


Additionally, class UserDatabasePrincipal is NOT serializable. That 
means, it gets dropped when sessions and principals get persisted and 
reloaded. That applies to session persistence across restarts (with 
persistAuthentication set to true) and likely to clustering/HA. That's 
not fatal, but after a restart or when running on a different cluster 
node, users suddenly get a full-blown GenericPrincipal instance when 
they call Request.getUserPrincipal(). However, since nobody complained 
about it, the UserDatabasePrincipal is likely not so important :-p


I suspect the users that worry about that sort of thing aren't using the 
UserDatabaseRealm but it would be nice to fix that anyway.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: Additional user attributes queried by (some) realms

[Carsten Klein]

Hi Mark,

thanks for sharing your ideas :)

On 26/05/2021 19:56, Mark Thomas wrote:

Given that the attributes may well be security related, you would need 
to make sure neither the Map nor any of the keys/values could be 
modified. Protecting the Map is easy. Protecting the keys/values is a 
little trickier. For that reason I'd lean towards the solution below.


Oh yes, these attributes should likely be immutable. Since I still 
believe that Enumerations are kind of uncomfortable (and outdated?), 
what about strictly relying on Collections.unmodifiableMap?


But, I'm ok with getAttribute(String name) and getAttributeNames() pair 
as well. You decide :)


My first idea was to allow users to put their own attributes as well. 
But then, we'd need to track Realm-sourced attribute names and make 
those read-only in a setAttribute method. Since users could as well put 
their stuff into session attributes, making the whole map immutable is 
possible and clearly much simpler.


2. Should I add attributes-related public methods to the 
TomcatPrincipal interface as well?


Yes. So far the only Tomcat specific extensions are for SPNEGO but this 
is in the same category. The other option would be a new interface but I 
don't see a need for that.


Since UserDatabasePrincipal is a private inner class of 
UserDatabaseRealm, no instanceof checks are possible to determine 
whether attributes may be available or not. So, I was thinking of a new 
interface


public interface AttributedPrincipal extends Principal {

  public Object getAttribute(String name);

  Enumeration getAttributeNames();

}

That interface has a slightly more meaningful name for consumers of 
additional user attributes. But adding these methods to TomcatPrincipal 
is good as well.




3. Class UserDatabasePrincipal in UserDatabaseRealm


Why does UserDatabaseRealm pass a userPrincipal of type 
UserDatabasePrincipal? Can't we just drop that and do it like 
JNDIRealm or DataSourceRealm?


I don't see any obvious reason. I'll do some digging in the source 
history to see if I can find out why. Absent a good reason, I'd say 
drop it.


There is a good reason for it, but I think it should be possible to drop 
it.


It is there because the UserDatabaseRealm supports the concepts of 
groups. Users can have roles assigned directly or users can be assigned 
to a group and inherit the roles of the group. This means hasRole() is a 
little more complicated and the UserDatabasePrincipal is used to 
determine if this additional processing is required.


I think this could be replaced by a 
"org.apache.catalina.realm.UserDatabaseRealm.groups" attribute which 
would remove the need for the dedicated UserDatabasePrincipal


Honestly, I don't see that in the code. What I see is, that 
UserDatabaseRealm resolves roles coming from groups up front in its 
getPrincipal method. After that, it just creates an ordinary 
GenericPrincipal instance with a single list of effective roles.


The associated UserDatabasePrincipal does nothing special with 
hasRole(). Its only method is getName(). So, it just removes or "hides" 
any special GenericPrincipal methods like hasRole() and getRoles() from 
the user (aka from the Servlet code, internally Tomcat still uses the 
surrounding GenericPrincipal, e. g. for authorization).


So, the only thing UserDatabasePrincipal does, is to hide the fact that 
groups have already been resolved to a single list of effective roles, 
the Principal is working with during its lifetime. Did I overlook something?


Actually, when declaring the attributes-related methods in a public 
interface (either TomcatPrincipal or AttributedPrincipal), adding that 
interface to UserDatabasePrincipal is not expensive. So, we could always 
decide to leave that UserDatabasePrincipal in place and let it implement 
that interface.


However, in order to not "pollute" UserDatabasePrincipal with unneeded 
methods, I'd vote for using a new 
org.apache.catalina.AttributedPrincipal interface.


Additionally, class UserDatabasePrincipal is NOT serializable. That 
means, it gets dropped when sessions and principals get persisted and 
reloaded. That applies to session persistence across restarts (with 
persistAuthentication set to true) and likely to clustering/HA. That's 
not fatal, but after a restart or when running on a different cluster 
node, users suddenly get a full-blown GenericPrincipal instance when 
they call Request.getUserPrincipal(). However, since nobody complained 
about it, the UserDatabasePrincipal is likely not so important :-p


Carsten

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org