-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Lee,

On 10/9/18 08:11, Lee Broom wrote:
> Hello My aim is to introduce a domain level
> authentication/authorisation security layer when accessing the
> http://localhost:8080/sample/ application. I don't want this web
> application to be openly accessible and without challenging an
> operator.

You should be using HTTPS. This won't cause an erorr, but it is not a
secure configuration.

> After a frustrating and fruitless week I now reach out to the
> apache community for assistance because I have been unsuccessful
> enabling this function. The current behaviour is that
> http://localhost:8080/sample does not throw a login prompt.
> 
> I can only assume it is caused by my Apache Tomcat code snippet
> configuration is all wrong. I am running version Apache
> Tomcat/7.0.91 on Redhat 7 in an ec2 AWS instance. I have installed
> and integrated Winbind on the OS and is happily talking to my AD
> domain example.com. Confirmation of this is realm connecting
> successful, I can see groups and users and I have masked the domain
> format 'example/user1' so it appears as 'user1'. Other factors; 1)
> I have found similar issues posted by others but none of the
> solutions worked for me 2)There are no errors found within
> /usr/local/tomcat7/logs/.

If you have the option, I'd use a more recent version of Tomcat. It
sounds like you are starting from scratch, so using e.g. Tomcat 9
should not represent too much of a burden.

> I had downloaded and installed sample.war from
> https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/ into my
> tomcat installation /usr/local.tomcat7/webapps/ directory.
> 
> I would appreciate any assistance or a hefty kick in the right
> direction.
> 
> There are 3 files in total that I have attempted to configure;
> /conf/server.xml, /webapps/sample/WEB-INF/web.xml &
> /conf/tomcat-users.xml
> 
> My JNDI Realm entry in /usr/local/tomcat7/conf/server.xml
> configuration looks like this: 
> ----------------------------------------------------------------------
- ----------------
>
> 
<Realm className="org.apache.catalina.realm.JNDIRealm"
> debug="99"

What's the "debug for?

> connectionURL="ldap://example.com:389";

You should be using LDAPS. This won't cause an error, but it is not a
secure configuration.

> authentication="simple" referrals="follow" 
> connectionName="ou=users,ou=lab,dc=example,dc=com" 
> userSearch="(sAMAccountName={0})" userBase="dc=example,dc=com" 
> userSubtree="true" roleSearch="(member={0})" roleName="cn" 
> roleSubtree="true" roleBase="ou=users,ou=lab,dc=example,dc=com" />

This all looks okay to me at first glance, but I haven't set up Tomcat
LDAP authentication before.

Where is your <Realm> defined in conf/server.xml? Within the <Engine>
or <Host> where your application will live? If not, it needs to be in
one of those places. If you just replaced the existing <Realm> from
the stock conf/server.xml file, then you should be good.

> ----------------------------------------------------------------------
- ----------------
>
>  Also, I have commented the following: 
> ----------------------------------------------------------------------
- ----------------
>
> 
<!-- <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
> resourceName="UserDatabase"/> --> 
> ----------------------------------------------------------------------
- ----------------
>
>  My /usr/local/tomcat7/webapps/sample/WEB-INF/web.xml file looks
> like this: 
> ----------------------------------------------------------------------
- ----------------
>
> 
<?xml version="1.0" encoding="ISO-8859-1"?>
> <web-app xmlns="http://java.sun.com/xml/ns/j2ee"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4">
> 
> <display-name>Hello, World Application</display-name> 
> <description> This is a simple web application with a source code
> organization based on the recommendations of the Application
> Developer's Guide. </description>
> 
> <servlet> <servlet-name>HelloServlet</servlet-name> 
> <servlet-class>mypackage.Hello</servlet-class> </servlet>
> 
> <servlet-mapping> <servlet-name>HelloServlet</servlet-name> 
> <url-pattern>/hello</url-pattern> </servlet-mapping>
> 
> <security-constraint> <web-resource-collection> 
> <web-resource-name>Entire Application</web-resource-name> 
> <url-pattern>/*</url-pattern> </web-resource-collection> 
> </security-constraint>

You have a security-constraint which covers the entire URL space and
does not require any user roles. As explained in [1]:

"
An authorization constraint establishes a requirement for
authentication and names the roles authorized to access the URL
patterns and HTTP methods declared by this security constraint. If
there is no authorization constraint, the container must accept the
request without requiring user authentication.
"

I believe this is the core of your problem.

> <!-- This application has two basic areas;
> --> <!--    the webroot of the application accessed by all
> users(/MyWebApp)         --> <!--    and the admin pages
> (/MyWebApp/Admin)                                   --> <!-- We
> assign the role-name 'Users' to first, and 'Admin' to the second
> -->
> 
> <security-constraint> <display-name>All Users</display-name> 
> <web-resource-collection> <web-resource-name>All
> Users</web-resource-name> <url-pattern>/*</url-pattern> 
> </web-resource-collection> <auth-constraint> 
> <role-name>User</role-name> </auth-constraint> 
> </security-constraint>

You have mapped a second security-constraint to the same URL space.

> <security-constraint> <display-name>Admin Users</display-name> 
> <web-resource-collection> <web-resource-name>Admin
> Users</web-resource-name> <url-pattern>/*</url-pattern> 
> </web-resource-collection> <auth-constraint> 
> <role-name>Admin</role-name> </auth-constraint> 
> </security-constraint>

You have mapped a third security-constraint to the same URL space.

In case of a conflict, I believe the "let everyone in" constraint,
specified first above, will win.

> <security-role> <description>Webapp Admins</description> 
> <role-name>Admin</role-name> <group-name>domain
> admins</group-name> </security-role>
> 
> <security-role> <description>Webapp Users</description> 
> <role-name>User</role-name> <group-name>domain users</group-name> 
> </security-role>
> 
> <login-config> <auth-method>BASIC</auth-method> 
> <form-login-config>/sample/login.html</form-login-config> 
> <form-error-page>/sample/error_login.jsp</form-error-page> 
> </login-config>
> 
> </web-app> 
> ----------------------------------------------------------------------
- ----------------
>
>  The only change made to /usr/local/tomcat7/conf/tomcat-users.xml
> is the additional text: 
> ----------------------------------------------------------------------
- ----------------
>
> 
<role rolename="User"/>
> <role rolename="Admin"/> <user username="user1" password="******"
> roles="User,Admin"/> 
> ----------------------------------------------------------------------
- ----------------

Changes
> 
to tomcat-users.xml should not affect anything, since you are
attempting to use LDAP for authentication. If you ARE attempting to
use conf/tomcat-users.xml for authentication, then take care to
un-comment the entire block of configuration.

It might not be a bad idea to get everything working with the
UserDatabaseRealm since you are likely to have to try a few things
wiht your LDAP configuration to get it working. Making sure that the
authentication itself is working as expected (with an "easy" realm)
before tackling LDAP might be worth your time.

Hope that helps,
- -chris

[1] https://docs.oracle.com/cd/E19798-01/821-1841/bncbk/index.html
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+D1wACgkQHPApP6U8
pFhMKg/+JQ2J1m6PqrS1smYIWACs056DC432JqqnSjjbLXT/C9wI1sDxWAwwX9ll
Og6EVZ4DU/2qzdgyc4Vb3//HY6zVZ3fRDeqwFuHkHd9cn3Vjry9JF487Ei2/afGp
I7l2f7ns3Ya2s8Dt0NXkqzsgMIW5nXJzmoMBeHXBOwozBDwvPR9n4uU0nCVJ8uqP
YuSAJq7Ou7h5A8lhpJARMdAPcBNuUZRVX834EL7/RJ94p7znULiebtMqqZartUA4
hOgJn3mAllDiiNJU7brR5umuhYFWelErgkF4jmeT/c0ceehesJKBFd/bS2DubNyJ
0dJUpnv6m+kBvwoFSJ7JTnpKkPybuYG5T1otDHTceEC+0O3eJeVzeN22pqSWpil8
3UxWz2ysC3C/QT0MzgHwqENOaZ+g8gyCGn4WXP0tPkVbYDop1mOicBW8eY8MFo2v
4cpewhHqrAqivdCdvCZFdi9Y0NoSzLP8k91U3nqOQ7xQvSQ972M2F9E9WWArdugw
R8pG5MNrPYYtZsBdYBv3pqY65RQNxGGNfzu+PtOAw2+torKso96TnIDhrBwyyj0P
vlbDKNs5z1WkKoMwQOq2CswE9ZbJtfLuC4pjdnLJHpIA0/QxxkoDK4SG6zpt/juh
AV7nJSXZhvsxFDJrql4MAOlBmRETuiRtpqF6yGW38ZKhuhgtvio=
=/eC+
-----END PGP SIGNATURE-----

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

Reply via email to