• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Help in configuring Active Directory for Login Authentication using role.

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
 I have created a Login html page that authenticates the users based on role, for that I am configuring the users in Tomcat-user.xml. But now we need to authenticate the users using Active Directory and I am not sure how to configure this as I am new to tomcat/Apache. Does this configuration need to be done at Apache level or can it be done similar to the way we did for using tomcat-user.xml . We need to allow a specific group of users to access the page and not all.

Current configuration in code
web.xml
<login-config>
   <auth-method>FORM</auth-method>
   <form-login-config>
     <form-login-page>/TestLogin.html</form-login-page>
     <form-error-page>/TestError.html</form-error-page>
   </form-login-config>
 </login-config>

<security-constraint>
   <web-resource-collection>
     <web-resource-name>Login admin</web-resource-name>
     <url-pattern>/login.html</url-pattern>
   </web-resource-collection>
   <auth-constraint>
     <role-name>loginrole</role-name>
   </auth-constraint>
 </security-constraint>
 
 Tomcat-user.xml
 <role rolename="loginrole"/>
<user username="tomcat" password="tomcat" roles="loginrole"/>
</tomcat-users>

LoginPage
<form method="POST" action="j_security_check">
   <div class="form-group"><input type="text" name="j_username" id="j_username" placeholder="Username" class="form-control resetval"></div>
   <div class="form-group"><input type="password" name="j_password" id="j_password" placeholder="Password" class="form-control resetval"></div>
   <input type="submit" value="Submit" class="btn btn-default">
 </form>

Thanks for all the help in advance!

Thanks,
Anju
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tomcat uses a plug-in architecture for J2EE standard security. These security plugins are called Realms. The standard Realm that comes defined in the server.xml file is the MemoryDatabaseRealm and it's just a simple module that reads data from the tomcat-users.xml file.

But many other Realm modules exist as well. The JDBC Realm, for example, is used when you have your userids, passwords, and roles defined in a SQL database.

Active Directory is a subset of LDAP which is accessed using the Java Naming and Directory interface (JNDI) and therefore you would use the JNDIRealm. To configure a JNDIRealm for Active directory, see this topic:

http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#JNDIRealm

The configuration is pretty much the same for all recent versions of Tomcat. I just picked Tomcat 7 randomly.
 
A Nair
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Thank you Tim for the information! This helps a lot.

Just one quick question on role in realm configuration. As per requirement only loginrole user should be able to login, so would stating the expected role as part of roleName property suffice, or do we have to explicitly write the code to check the role once authentication is done ?

<Realm   className="org.apache.catalina.realm.JNDIRealm"
    connectionURL="ldap://localhost:389"
      userPattern="uid={0},ou=people,dc=mycompany,dc=com"
         roleBase="ou=groups,dc=mycompany,dc=com"
         roleName="cn"
       roleSearch="(uniqueMember={0})"
/>
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You cannot create a "login" role. Until a user is logged in (authenticated), you don't know who that user is, much less what role(s) they operate under. The closest approximation to a "login role" would be to remove the user from the credentials data or change the user's password to something the user does not know and cannot guess.

Authentication is triggered by an attempt to access a secured URL, as defined by the security URL patterns in your app's web.xml file. Authorization is done, once the user has authentication (and ONLY IF a user has authenticated successfuly), by the server asking its Realm if any of the roles assigned to that URL pattern are present in the Realm's list of roles assigned to that user. If not, the server rejects the URL request (403 FORBIDDEN) and the application logic is never offended by the unauthorized request (and therefore cannot be exploited by it).

Just to clarify the preceding: The login/loginfail pages have no URLs. A user cannot invoke them directly (if you do, it won't function properly). ONLY Tomcat can dispatch these pages and it does so automatically when a restricted URL is requested by an un-authenticated user. That gets rid of one of the most common exploits, which is to simply jump around the login page and go directly to the secured URL. Tomcat handles login if needed and when needed and there's no application logic involved.

There are also some role API methods, such as the HttpServletRequest isUserInRole() method that can be used to restrict access to application logic based on the user's roles;

The system might seem a little awkward until you realize that it has some essential properties, which can be synopsised as "Never Volunteer Information":

1. Access to secured resources is restricted at the server level where possible (Container Managed). Which, like I said, helps prevent attackers from exploiting possible weaknesses in the application logic. The server's logic is more isolated, thus less exploitable for specific business goals and also, of course, much better tested and maintained.

2. You cannot retrieve security information, only petition it. There's no API to return the user's password or role list, only APIs to check if the user can act in a role. This prevents "fishing expeditions" that would search for a privileged user ID and exploit it. And you never, never, never can access the password. In fact, the effective SQL for authentication is "SELECT COUNT(*) FROM USER WHERE USER_ID=? AND PASSWORD=?". The actual password never leaves the database server, so exploits cannot troll Tomcat for passwords. The worst that they could do would be to snoop user-submitted passwords and see what userid/password combinations validated. And even that would require major exploitation of Tomcat's internal logic.
 
A Nair
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for taking out time and explaining in such detail! This helped configure it at my end.

--Anju
 
reply
    Bookmark Topic Watch Topic
  • New Topic