2015-12-05 18:12 GMT+03:00 Marco Pizzoli <marco.pizz...@gmail.com>: > Hello Konstantin, > > On Sat, Dec 5, 2015 at 2:31 PM, Konstantin Kolinko <knst.koli...@gmail.com> > wrote: > >> 2015-12-05 12:18 GMT+03:00 Marco Pizzoli <marco.pizz...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
