On 19 March 2012 14:36, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Neil,
>
> On 3/19/12 6:35 AM, Neil Munro wrote:
>> This is the layout of my web.xml file:
>>
>> <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app
>> PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>> "http://java.sun.com/dtd/web-app_2_3.dtd";>
>>
>> <web-app version="2.4">
>
> Webapp version mismatch. This almost certainly isn't causing problems,
> but it will eventually. Pick one: 2.3 or 2.4 and stick with it.
>
>> <welcome-file-list>
>> <welcome-file>/WEB-INF/login/login.jsp</welcome-file>
>> </welcome-file-list>
>
> You don't want that. If you hit http://yourserver/context/ then you'll
> be redirected to /WEB-INF/login/login.jsp and you can't access
> anything in /WEB-INF/ directly like that. This is likely one of your
> initial problems.
>
> Instead, make "index.jsp" or something similar your <welcome-file> and
> then let the container redirect to the login page when authentication
> is necessary (that's how it works).
>
> I highly recommend that you go back and re-read the servlet
> specification sections on Form Authentication, even if you have read
> it already. It's short and readable and you are obviously a little
> rusty. Re-reading will be very helpful, I'm sure. Make sure you read
> the version of the spec that you are actually using, too ;)
>
>> <!-- LDAP stuff, hopefully! --> <security-constraint>
>> <web-resource-collection> <web-resource-name>Public
>> Area</web-resource-name> <!-- Define the context-relative URL(s) to
>> be protected --> <!--url-pattern/jsp/*/url-pattern-->
>> </web-resource-collection> <auth-constraint> <!-- Anyone with one
>> of the listed roles may access this area --> <role-name>my company
>> users</role-name> </auth-constraint> </security-constraint>
>
>
> You will need a <url-pattern> in <web-resource-collection>. Otherwise,
> you aren't protecting anything. Your log file shows that no security
> constraints are applicable, so there is no reason to request
> authentication from the user.
>
> Try setting the <url-pattern> to:
>
> <url-pattern>/*</url-pattern>
>
> That will protect the entire webapp.
>
> You don't need your "protected area" security constraint at all, since
> the container will never allow direct-access to /WEB-INF.
>
>> <!-- uses form-based authentication --> <login-config>
>> <auth-method>FORM</auth-method> <form-login-config>
>> <form-login-page>/WEB-INF/login/login.jsp</form-login-page>
>> <form-error-page>/WEB-INF/login/fail_login.jsp</form-error-page>
>> </form-login-config> </login-config>
>>
>> <!-- Security roles referenced by this web application -->
>> <security-role> <role-name>my company users</role-name>
>> </security-role>
>
> Also looks good.
>
>> There is a login directory under WEB-INF with the files inside it,
>> but I just get a 404 error when I try to access the pages that way,
>> I don't understand how this format works, if /login.jsp refers to
>> the login.jsp file located under the jsp directory
>
> It doesn't.
>
>> how does /WEB-INF mean the WEB-INF directory at the same level as
>> jsp and not a directory inside jsp called WEB-INF?
>
> It doesn't.
>
> It sounds like your file structure looks like this:
>
> - - webapp
> |- jsp
> |- WEB-INF
> |- WEB-INF/login
>
> If you have all your /other/ JSP files under webapp/jsp, then you'll
> have to access them using a URL like /webapp/jsp/whatever.jsp. You
> cannot request /WEB-INF/login/login.jsp because the container is
> required to veto such requests. Instead, request another resource...
> the container is allowed to serve indirect requests to
> /WEB-INF/login/login.jsp and so that's what it will do.
>
>> I have been informed there's a global user in the system that can
>> be used to make the initial connection, so my realm config looks
>> like this now: <Realm
>> className="org.apache.catalina.realm.JNDIRealm"
>> connectionName="uid=connectuser,ou=my company
>> users,dc=mycompany,dc=com" connectionPassword="parliament"
>
> That seems like a reasonable thing to do. Anonymous bind might be
> better so you don't have to put any credentials into your server.xml
> file, but you are certainly using a non-privileged user for this, right?
>
>> connectionURL="ldap://my.ldap.server";
>> alternateURL="ldap://my.ldap.server"; userBase="ou=my company
>> users,dc=mycompany,dc=com" userSearch="(sAMAccountName={0})"
>> userPattern="uid={0},ou=my company users,dc=mycompany,dc=com"
>> userPassword="userpassword"
>
> This will configure JNDIRealm to take the user's password, hash it
> (except not in your case since you haven't set a "digest" attribute)
> and then compare it to the user's "userpassword" attribute.
>
>> roleBase="ou=my company users,dc=mycompany,dc=com"
>> roleSubtree="true" roleName="cn" roleSearch="(uniqueMember={0})"
>> />
>>
>> By working what I mean is that with the connection user in place,
>> I get a list of users populating the selection box in the html page
>> so the query runs and returns what I expect it to, but I still
>> cannot get the system to verify a user and take them to a page
>> inside the web app.
>
> That means it's not working. The above configuration will only
> configure your Realm and not anything you are using to sniff
> usernames, etc.
>
>> It looks to me (admittedly no expert) that it's unable to find
>> something, I presume that with me using files stored in
>> WEB-INF/login and getting a 404 error that this is all related. I
>> moved the files from WEB-INF/login back to JSP and tried again
>> getting this:
>
> You aren't reading the problem correctly. The problem is that your
> webapp does not require authentication due to your (lack of)
> <security-constraint> configuration.
>
>> I can see that since I no longer get a 404 error and that the
>> files are being listed now that I was correct in that files were
>> not being found for whatever reasons, however I was dedirected back
>> to the failed login page after trying to access the suites.jsp
>> page. I don't see anything in the log about failing to authenticate
>> a user or anything like that.
>
> So Tomcat showed you the login page but you didn't get any log
> messages about it trying to authenticate?
>
> Hmm. Maybe we need to see that login.jsp again.
>
>> I am guessing that perhaps the passwords are not being checked or
>> sent correctly for authentication, I know that sometimes tomcat
>> doesn't allow plain text passwords, but I am more tempted to think
>> that perhaps I still have a misconfigured server.xml file to check
>> the entered details.
>
> If your LDAP server stores passwords in plain text (which would be a
> terrible idea) then your configuration is correct. If, instead, you
> are using a message digest (aka hash), then you need to configure that
> using the "digest" attribute on your <Realm>.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9nRHMACgkQ9CaO5/Lv0PAbnwCfcDazw6+r7j3Z5DApE5xnlXuR
> wH8AnAtXhooT1M6MPqeFdjn4jCPb9UBZ
> =Pmjg
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
Sorry about that mismatch, I totally missed that and have corrected it
now. Stuck with version 2.3.
My welcome page is now index.jsp, which has a href to suites.jsp, a
file that I wish to protect and require a user login to access.
I have also discovered why I was unable to access the files stored in
WEB-INF, I needed to write a quick few lines in my build.xml to copy
the login and fail_login into the web app. So that's solved now,
however it's still just looping around, however I have been informed
by our sysadmin that while the passwords are stored encrypted, we do
not (yet) enforce ssl and ultimately the passwords are transmitted in
plain text, so I am not sure how that will affect my config file.
So my web.xml now looks like this:
<security-constraint>
<web-resource-collection>
<web-resource-name>Public Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected
-->
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- Anyone with one of the listed roles may access
this area -->
<role-name>my company users</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected
-->
<url-pattern>/suites.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- Anyone with one of the listed roles may access this area
-->
<role-name>my company users</role-name>
</auth-constraint>
</security-constraint>
<!-- uses form-based authentication -->
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/WEB-INF/login/login.jsp</form-login-page>
<form-error-page>/WEB-INF/login/fail_login.jsp</form-error-page>
</form-login-config>
</login-config>
I can access the login and fail_login files correctly as you have
described. But again I can't gain access to suites.jsp yet, I
suspected digest passwords are what I am missing, but until my sys
admin gets back to me on the hash type I have no idea. Though I have
read it's always MD5 because HTTP authentication cannot support
anything else. I also included the "uniqueMember:=" correction, just
in case it stings me too.
So this is my server.xml file at the moment, with the digest attribute included:
<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionName="uid=connectuser,ou=my company
users,dc=mycompany,dc=com"
connectionPassword="parliament"
connectionURL="ldap://my.ldap.server.com";
alternateURL="ldap://my.ldap.server.com";
digest="MD5"
userBase="ou=my company users,dc=mycompany,dc=com"
userSearch="(cn={0})"
userPattern="uid={0},ou=my company users,dc=mycompany,dc=com"
userPassword="{1}" <!-- if {0} is username is {1} not the
password? -->
roleBase="ou=my company users,dc=mycompany,dc=com"
roleSubtree="true"
roleName="cn"
roleSearch="(uniqueMember:={0})" <!-- Included the ":" as warned
about the potential issue -->
/>
Thanks,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
