You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Marco Pizzoli <ma...@gmail.com> on 2015/12/05 10:18:08 UTC

WebApp to WebApp JEE security

Hi list,
I am fighting against a 3rd party application composed by 2 webapps.

The first is supposed to present a login form and once authenticated you
are presented with the application frontend.
Behind the lines it is connecting (through localhost) to a second one that
is presenting the same security configuration.
In short, the same username/role are authorized for the second aplication
as well.

In the original setup everything works fine with the memoryRealm, so just
populating the tomcat-users.xml file.
Problems arose when I switched to leverage JNDIRealm (LDAP): it is not
working anymore.
I easily managed to get the first app to authenticate against LDAP,
validating a specific LDAP group, but eventually the app gets 403 in
accessing the second one.

Of course I already tried the same security-role / security-contraint in
both the web.xml.

Do you know if it is a known problem in "sharing" a security mechanism
between webapps running on the same Tomcat?
I am running Tomcat 7.0.64.

I did not found a way to debug the security-contraint/security-role stuff.
If you could just advice what to enable to have a deeper insight... that
would be invaluable!

Thanks to all
Marco

Re: WebApp to WebApp JEE security

Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-12-05 18:12 GMT+03:00 Marco Pizzoli <ma...@gmail.com>:
> Hello Konstantin,
>
> On Sat, Dec 5, 2015 at 2:31 PM, Konstantin Kolinko <kn...@gmail.com>
> wrote:
>
>> 2015-12-05 12:18 GMT+03:00 Marco Pizzoli <ma...@gmail.com>:
>> > Hi list,
>> > I am fighting against a 3rd party application composed by 2 webapps.
>> >
>> > The first is supposed to present a login form and once authenticated you
>> > are presented with the application frontend.
>> > Behind the lines it is connecting (through localhost) to a second one
>> that
>> > is presenting the same security configuration.
>> > In short, the same username/role are authorized for the second aplication
>> > as well.
>>
>> What do you mean by "connecting"?
>>
>
> It is connecting to https://<same_hostname>/context2/<balbla>
> In /etc/hosts I put "same_hostname" to point to 127.0.0.1
>

How it configures the password used by this second connection?

Does it process the session cookie (and session id) that the second
web application would create for this request?

>> A cross-context Servlet API call (getContext(String name)), and the
>> first application has crossContext="true" on its Context element [1]?
>>
>
> No, it wasn't. I tried setting it up, but without success...
>
>
>>
>> A network connection to 127.0.0.1 ?
>>
>> [1] http://tomcat.apache.org/tomcat-8.0-doc/config/context.html
>
>
> I did look at that link, but still can't understand how this attribute
> should help me...
>

It allows to retrieve a ServletContext of another web application and
to perform dispatch / forward of original request to that application.
You are not creating a new network connection here. This dispatch is
performed by the original request processing thread.

Without that "crossContext" flag such cross-context dispatch calls are
disallowed for security reasons.

> <...>
>>
>> Constraints and roles check is performed by an Authenticator valve
>> [2]. There are several kinds of them - one is selected based on your
>> login configuration. The base operations are common between them,
>> implemented in base class
>> (org.apache.catalina.authenticator.BasicAuthenticator).
>>
>> A Realm is called to perform password checks etc.,
>> but see also its common class (RealmBase) with methods such as
>> RealmBase.findSecurityConstraints(..), hasResourcePermission(), ...
>>
>>
> I understand, but what I am asking if is there a way to enable "debug"
> logging on the "security engine" that on the second webapp is producing
> "403" as response...

You need to look into the source code.
You need to add a
<package>.<classname>.level = FINE
line to conf/logging.properties file and restart Tomcat.

The <package>.<classname> is the name of the class that is used to
create an instance of Log class.
E.g. if it is creates as
    private static final Log log = LogFactory.getLog(RealmBase.class);
then you need
org.apache.catalina.realm.RealmBase.level=FINE

If it is created as LogFactory.getLog(this.getClass()); then you need
to figure out, what class is "this".

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


Re: WebApp to WebApp JEE security

Posted by Marco Pizzoli <ma...@gmail.com>.
Hello Konstantin,

On Sat, Dec 5, 2015 at 2:31 PM, Konstantin Kolinko <kn...@gmail.com>
wrote:

> 2015-12-05 12:18 GMT+03:00 Marco Pizzoli <ma...@gmail.com>:
> > Hi list,
> > I am fighting against a 3rd party application composed by 2 webapps.
> >
> > The first is supposed to present a login form and once authenticated you
> > are presented with the application frontend.
> > Behind the lines it is connecting (through localhost) to a second one
> that
> > is presenting the same security configuration.
> > In short, the same username/role are authorized for the second aplication
> > as well.
>
> What do you mean by "connecting"?
>

It is connecting to https://<same_hostname>/context2/<balbla>
In /etc/hosts I put "same_hostname" to point to 127.0.0.1


> A cross-context Servlet API call (getContext(String name)), and the
> first application has crossContext="true" on its Context element [1]?
>

No, it wasn't. I tried setting it up, but without success...


>
> A network connection to 127.0.0.1 ?
>
> [1] http://tomcat.apache.org/tomcat-8.0-doc/config/context.html


I did look at that link, but still can't understand how this attribute
should help me...


>
>
> > In the original setup everything works fine with the memoryRealm, so just
> > populating the tomcat-users.xml file.
> > Problems arose when I switched to leverage JNDIRealm (LDAP): it is not
> > working anymore.
> > I easily managed to get the first app to authenticate against LDAP,
> > validating a specific LDAP group, but eventually the app gets 403 in
> > accessing the second one.
> >
> > Of course I already tried the same security-role / security-contraint in
> > both the web.xml.
> >
> > Do you know if it is a known problem in "sharing" a security mechanism
> > between webapps running on the same Tomcat?
> > I am running Tomcat 7.0.64.
> >
> > I did not found a way to debug the security-contraint/security-role
> stuff.
> > If you could just advice what to enable to have a deeper insight... that
> > would be invaluable!
>
> Constraints and roles check is performed by an Authenticator valve
> [2]. There are several kinds of them - one is selected based on your
> login configuration. The base operations are common between them,
> implemented in base class
> (org.apache.catalina.authenticator.BasicAuthenticator).
>
> A Realm is called to perform password checks etc.,
> but see also its common class (RealmBase) with methods such as
> RealmBase.findSecurityConstraints(..), hasResourcePermission(), ...
>
>
I understand, but what I am asking if is there a way to enable "debug"
logging on the "security engine" that on the second webapp is producing
"403" as response...


> [2]
> http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Authentication
>
> Best regards,
> Konstantin Kolinko
>

Thank you very much for your help.
Marco


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

Re: WebApp to WebApp JEE security

Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-12-05 12:18 GMT+03:00 Marco Pizzoli <ma...@gmail.com>:
> Hi list,
> I am fighting against a 3rd party application composed by 2 webapps.
>
> The first is supposed to present a login form and once authenticated you
> are presented with the application frontend.
> Behind the lines it is connecting (through localhost) to a second one that
> is presenting the same security configuration.
> In short, the same username/role are authorized for the second aplication
> as well.

What do you mean by "connecting"?

A cross-context Servlet API call (getContext(String name)), and the
first application has crossContext="true" on its Context element [1]?

A network connection to 127.0.0.1 ?

[1] http://tomcat.apache.org/tomcat-8.0-doc/config/context.html

> In the original setup everything works fine with the memoryRealm, so just
> populating the tomcat-users.xml file.
> Problems arose when I switched to leverage JNDIRealm (LDAP): it is not
> working anymore.
> I easily managed to get the first app to authenticate against LDAP,
> validating a specific LDAP group, but eventually the app gets 403 in
> accessing the second one.
>
> Of course I already tried the same security-role / security-contraint in
> both the web.xml.
>
> Do you know if it is a known problem in "sharing" a security mechanism
> between webapps running on the same Tomcat?
> I am running Tomcat 7.0.64.
>
> I did not found a way to debug the security-contraint/security-role stuff.
> If you could just advice what to enable to have a deeper insight... that
> would be invaluable!

Constraints and roles check is performed by an Authenticator valve
[2]. There are several kinds of them - one is selected based on your
login configuration. The base operations are common between them,
implemented in base class
(org.apache.catalina.authenticator.BasicAuthenticator).

A Realm is called to perform password checks etc.,
but see also its common class (RealmBase) with methods such as
RealmBase.findSecurityConstraints(..), hasResourcePermission(), ...


[2] http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Authentication

Best regards,
Konstantin Kolinko

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