Re: How does the user principal get set on the servlet container session?
On 01/02/2024 17:48, Ryanesch@yahoo wrote:
On Feb 1, 2024, at 10:34 AM, Mark Thomas wrote:
On 31/01/2024 00:15, Ryan Esch wrote:
From what I understand, the container knows if a user is authenticated by
using the session id passed to it and then looking up the user principal. If
this is non-null, the user is authenticated. I am using web.xml with security
constraints and UsersRoleLoginModule defined in jaas.conf which is working
fine. I want to add an additional method of login.
How do I set the principal on the session in my custom login module?
Is this a JAAS login module or something else?
I have tried a number of things, including:
HttpSession session = request.getSession();
// Retrieve or create the Subject
Subject subject = (Subject) session.getAttribute("javax.security.auth.subject");
if (subject == null) {
subject = new Subject();
session.setAttribute("javax.security.auth.subject", subject);
}
subject.getPrincipals().size());
Principal customPrincipal = new CustomPrincipal("Random Username");
subject.getPrincipals().add(customPrincipal);All my calls to
request.getUserPrincipal() are null so of course my custom login
fails.Alternatively/additionally, can I configure the container to also check
for an access token for authentication?
Thank you for any input or advice. I'd be happy to share additional details.Ryan
Take a look at AuthenticatorBase.register()
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Yes, this is jaas. I’ve realized that if I use jboss’ SimplePrincipal to create
my principal, the user principal is finally set on the subject. However, when I
use a custom principal, it is not set on the subject correctly. Even if I copy
SimplePrincipal exactly or extend it. Note that “correctly” means that I get
something returned from request.getUserPrincipal. There must be something
behind the scenes that checks for exactly SimplePrincipal?
https://tomcat.apache.org/tomcat-11.0-doc/config/realm.html#JAAS_Realm_-_org.apache.catalina.realm.JAASRealm
Search for userClassNames. You may also need roleClassNames.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Cookie Logging
Dan,
On 2/1/24 11:54, Dan McLaughlin wrote:
I was able to identify the problem - there was a session configuration with
cookie configuration in the catalina-base/web.xml file.
catalina-base/conf/web.xml?
I did mention on 26 Jan that this wasn't a good idea and could be
causing this kind of problem. Whatever is in the application's
WEB-INF/web.xml file should override the global setting, though. If you
are finding that it's not working that way, please file a bug.
I just wanted to suggest that it would be great if logging could be enabled
to show not only what the parameters were set to, but also where the
values came from. It seems like the sessionCookiePath could be resolved in
many ways, such as from the filename of the war, context.xml file name, the
sessionCookiePath, the cookie-config under the web.xml file in the
catalina-base/conf directory or from the web.xml packaged in the WAR. I
haven't had a chance to look at the logic in the Apache code, but this
would be a helpful addition and would have saved a lot of time trying to
debug where the value came from.
That may be a tall order. There are many many configurations settings
that can come from all over the place with defaults, default-defaults,
and spec-defined defaults. The session cookie path isn't particularly
special in this way... it just happens to be the one configuration
setting you are really really interested in, specifically.
Tracking exactly where a specific configuration setting came from would
likely require a lot of extra code for not much benefit.
-chris
On Thu, Feb 1, 2024 at 10:31 AM Mark Thomas wrote:
On 27/01/2024 14:38, Dan McLaughlin wrote:
Hey Mark,
If you see a bug report, then that will mean I was able to reproduce
it. I
see different behaviors in our local docker environment. Still, it's
nowhere as complex as our production environment--where everything is
clustered and behind load balancers, etc... It probably would be easier
for me to reproduce in our pre-prod environment and attach a debugger to
see where the / is coming from.
I glanced at the code, and SessionConfig is the only place setting the
CookiePath to / might happen. Would you agree?
} else {
// Only handle special case of ROOT context where cookies require a
// path of '/' but the servlet spec uses an empty string
if (contextPath.length() == 0) {
contextPath = "/";
}
There are other places such as the RewriteValve. I think debugging is
your best option here.
Mark
-
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: Cannot start java issue after Tomcat9 and JDK 11 updates
Lori, On 2/1/24 10:35, Lori Kilen wrote: Hello, I have a Windows server (v2019) and I've updated java to Corretto jdk11.0.22_7 and Tomcat to 9.0.85. I added Tomcat as a Windows Service. I can start Tomcat from CMD using startup.bat and I can open localhost:8080 in a browser to display Tomcat page. But I cannot start Tomcat from javaw. I get the following entries in the log file: [info] [ 8024] Apache Commons Daemon procrun (1.3.4.0 64-bit) started. [info] [ 8024] Running Service 'Tomcat9'... [info] [ 8748] Starting service... [error] [ 6892] FindClass org/apache/catalina/startup/Bootstrap failed [error] [ 6892] The system cannot find the file specified. [error] [ 8748] Failed to start Java [error] [ 8748] ServiceStart returned 4. [info] [ 8024] Run service finished. [info] [ 8024] Apache Commons Daemon procrun finished. My CLASSPATH="C:\Tomcat\bin\bootstrap.jar;C:\Tomcat\bin\tomcat-juli.jar" bootstrap.jar is present in Tomcat\bin, and the folder permissions for Tomcat mirror what is specified on another, working, server (Tomcat 9.0.62 with jdk and jre 1.8.0_331) I've searched the mail archives and online, and found similar questions, but those solutions have not resolved this issue. At this point, I've removed all Java options in javaw. Can anyone provide any guidance to resolve this issue? After you upgraded Tomcat and Jav, did you remove any existing Windows Service and re-install it? One might usually do that using the bin\service.bat script, but there are other ways. If you didn't remove/reinstall the service, did you edit the existing service to ensure that your catalina.home and catalina.base system properties (in the Java tab) were set to the correct locations? And did you update the Java binary to point to the newly-installed Java? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Cookie Logging
Hey Mark,
I was able to identify the problem - there was a session configuration with
cookie configuration in the catalina-base/web.xml file.
I just wanted to suggest that it would be great if logging could be enabled
to show not only what the parameters were set to, but also where the
values came from. It seems like the sessionCookiePath could be resolved in
many ways, such as from the filename of the war, context.xml file name, the
sessionCookiePath, the cookie-config under the web.xml file in the
catalina-base/conf directory or from the web.xml packaged in the WAR. I
haven't had a chance to look at the logic in the Apache code, but this
would be a helpful addition and would have saved a lot of time trying to
debug where the value came from.
--
Thanks,
Dan
On Thu, Feb 1, 2024 at 10:31 AM Mark Thomas wrote:
>
>
> On 27/01/2024 14:38, Dan McLaughlin wrote:
> > Hey Mark,
> >
> > If you see a bug report, then that will mean I was able to reproduce
> it. I
> > see different behaviors in our local docker environment. Still, it's
> > nowhere as complex as our production environment--where everything is
> > clustered and behind load balancers, etc... It probably would be easier
> > for me to reproduce in our pre-prod environment and attach a debugger to
> > see where the / is coming from.
> >
> > I glanced at the code, and SessionConfig is the only place setting the
> > CookiePath to / might happen. Would you agree?
> >
> > } else {
> > // Only handle special case of ROOT context where cookies require a
> > // path of '/' but the servlet spec uses an empty string
> > if (contextPath.length() == 0) {
> > contextPath = "/";
> > }
>
> There are other places such as the RewriteValve. I think debugging is
> your best option here.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
*NOTICE:* This e-mail message and all attachments transmitted with
it are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure, or distribution is strictly prohibited. The contents of this
e-mail are confidential and may be subject to work product privileges. If
you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.
Re: How does the user principal get set on the servlet container session?
>
> On Feb 1, 2024, at 10:34 AM, Mark Thomas wrote:
>
> On 31/01/2024 00:15, Ryan Esch wrote:
>> From what I understand, the container knows if a user is authenticated by
>> using the session id passed to it and then looking up the user principal. If
>> this is non-null, the user is authenticated. I am using web.xml with
>> security constraints and UsersRoleLoginModule defined in jaas.conf which is
>> working fine. I want to add an additional method of login.
>> How do I set the principal on the session in my custom login module?
>
> Is this a JAAS login module or something else?
>
>> I have tried a number of things, including:
>> HttpSession session = request.getSession();
>> // Retrieve or create the Subject
>> Subject subject = (Subject)
>> session.getAttribute("javax.security.auth.subject");
>> if (subject == null) {
>> subject = new Subject();
>> session.setAttribute("javax.security.auth.subject", subject);
>> }
>> subject.getPrincipals().size());
>> Principal customPrincipal = new CustomPrincipal("Random Username");
>> subject.getPrincipals().add(customPrincipal);All my calls to
>> request.getUserPrincipal() are null so of course my custom login
>> fails.Alternatively/additionally, can I configure the container to also
>> check for an access token for authentication?
>> Thank you for any input or advice. I'd be happy to share additional
>> details.Ryan
>
> Take a look at AuthenticatorBase.register()
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
Yes, this is jaas. I’ve realized that if I use jboss’ SimplePrincipal to create
my principal, the user principal is finally set on the subject. However, when I
use a custom principal, it is not set on the subject correctly. Even if I copy
SimplePrincipal exactly or extend it. Note that “correctly” means that I get
something returned from request.getUserPrincipal. There must be something
behind the scenes that checks for exactly SimplePrincipal?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How does the user principal get set on the servlet container session?
On 31/01/2024 00:15, Ryan Esch wrote:
From what I understand, the container knows if a user is authenticated by
using the session id passed to it and then looking up the user principal. If
this is non-null, the user is authenticated. I am using web.xml with security
constraints and UsersRoleLoginModule defined in jaas.conf which is working
fine. I want to add an additional method of login.
How do I set the principal on the session in my custom login module?
Is this a JAAS login module or something else?
I have tried a number of things, including:
HttpSession session = request.getSession();
// Retrieve or create the Subject
Subject subject = (Subject) session.getAttribute("javax.security.auth.subject");
if (subject == null) {
subject = new Subject();
session.setAttribute("javax.security.auth.subject", subject);
}
subject.getPrincipals().size());
Principal customPrincipal = new CustomPrincipal("Random Username");
subject.getPrincipals().add(customPrincipal);All my calls to
request.getUserPrincipal() are null so of course my custom login
fails.Alternatively/additionally, can I configure the container to also check
for an access token for authentication?
Thank you for any input or advice. I'd be happy to share additional details.Ryan
Take a look at AuthenticatorBase.register()
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Cookie Logging
On 27/01/2024 14:38, Dan McLaughlin wrote:
Hey Mark,
If you see a bug report, then that will mean I was able to reproduce it. I
see different behaviors in our local docker environment. Still, it's
nowhere as complex as our production environment--where everything is
clustered and behind load balancers, etc... It probably would be easier
for me to reproduce in our pre-prod environment and attach a debugger to
see where the / is coming from.
I glanced at the code, and SessionConfig is the only place setting the
CookiePath to / might happen. Would you agree?
} else {
// Only handle special case of ROOT context where cookies require a
// path of '/' but the servlet spec uses an empty string
if (contextPath.length() == 0) {
contextPath = "/";
}
There are other places such as the RewriteValve. I think debugging is
your best option here.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Cannot start java issue after Tomcat9 and JDK 11 updates
Hello, I have a Windows server (v2019) and I've updated java to Corretto jdk11.0.22_7 and Tomcat to 9.0.85. I added Tomcat as a Windows Service. I can start Tomcat from CMD using startup.bat and I can open localhost:8080 in a browser to display Tomcat page. But I cannot start Tomcat from javaw. I get the following entries in the log file: [info] [ 8024] Apache Commons Daemon procrun (1.3.4.0 64-bit) started. [info] [ 8024] Running Service 'Tomcat9'... [info] [ 8748] Starting service... [error] [ 6892] FindClass org/apache/catalina/startup/Bootstrap failed [error] [ 6892] The system cannot find the file specified. [error] [ 8748] Failed to start Java [error] [ 8748] ServiceStart returned 4. [info] [ 8024] Run service finished. [info] [ 8024] Apache Commons Daemon procrun finished. My CLASSPATH="C:\Tomcat\bin\bootstrap.jar;C:\Tomcat\bin\tomcat-juli.jar" bootstrap.jar is present in Tomcat\bin, and the folder permissions for Tomcat mirror what is specified on another, working, server (Tomcat 9.0.62 with jdk and jre 1.8.0_331) I've searched the mail archives and online, and found similar questions, but those solutions have not resolved this issue. At this point, I've removed all Java options in javaw. Can anyone provide any guidance to resolve this issue? Thank you. -cuzi
