This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I want to configure LDAP in tomcat using tomcats's Realm.
for this i'm doing like below.
my server.xml (inside tomcat/conf) is,
and my web.xml (inside my web application) file is,
and my index.jsp is,
This what i have done,
Now After authentication is success, I want to redirect to the success page and where i want to display the user name and its role.
So can anyone tell me how to redirect to the success page from index.jsp. And how to get the roles from ldap using tomcat ldap configurations.
LDAP doesn't really factor in here. If you're using container-managed security, the normal method of operation is that the container security scans incoming URLs and if they match the patterns set up in web.xml, the incoming request will be sidetracked, the user signed on, then the original URL request will be resumed. In other words, the security system is transparent. This allows people to bookmark important URLs within the site while still maintaining security, and just as importantly, ensures that people don't have a way to sneak around the login process, which is one of the most common failings of the Do-it-Yourself login systems I've seen.
I did have an app where this behavior wasn't desired. The client demanded that the original URL be ignored and that post-login processing be routed to a home page, instead. What I did was write a servlet filter. There is at present, no hook to hand a login event on in J2EE - and, in fact with SSO systems such as portals or site-wide security, the login process may not have even been addressed to that applicaiton. So what I did was track the UserPrincipal in the HTTPSession object. If a request came through the filter and it had a non-null UserPrincipal, but there was no indicator in the HttpSession, I knew that a signon had just occurred, so I set the HttpSession indicator and redirected the URL to the home page.
An IDE is no substitute for an Intelligent Developer.
You can't "get the roles". Good security demands that the security system never volunteers anything (recall the SQL example I gave in the other topic). All you can do is query whether the user conforms to a given security role or roles and get back a yes/no answer.
If this make it seem difficult to allow a webapp to manage account info, that's because it is. But in a large enterprise, account management and security may span many applications, so user account maintenance is typically done by the corporate IT security group using a central control app.
Joined: Sep 17, 2009
Thanks for your reply.
If i didn't able to get the roles then how can i redirect the user to appropriate page ?
let us say I have an application where user can see user page and admin can see admin page.
Let us assume there are two uses namely user1 and admin1 and two roles USER, ADMIN. the user1 belongs to USER role/group and admin1 belongs to ADMIN role/group in LDAP. And in my application there are typically two pages one is user.jsp and another is admin.jsp.
If user1 is logged in then i need to redirect to user.jsp, for admin, admin.jsp.
That makes the common mistake of thinking a person can have only one role. In today's, um, efficient society, they fired the DBA, the network administrator and the accountant and gave all those jobs to the applications administrator.
What I did was make my "Home" page more of a portal page. If a person is authorized to act in the DBA role, the DBA parts of the home page are visible, likewise for the network administrator role, and so forth.
Of course, you CAN dispatch to separate pages. But you have to pick which role has priority an and have the filter query for that, then proceed downwards to lower-priority roles. One way you could do that without hard-coding it all in the filter would be to set up a mapping in the filter parameters in web.xml, where you'd set up a role/URL correspondence.
Joined: Sep 17, 2009
Hi Holloway,Thanks for your reply.
I think the following codwe can do my requirement.
Like this I need to metion several roles and corresponding urls? AM i right? And after authentication is hav\ppeng successfully, then the home page is not displaying? I think I did a mistake in some where. After login ais successfull , how to redirect or call a controller i.e a servlet. Do i need to mention the <url-pattern> in the above code ?
fo example I want to call the Servlet named LoginServelt , In this servlet I will find the role then dispatch the request appropriately..
for calling this servlet how to code in web.xml
I think in the above instead of this do i need to use like this? or something else.
can you make changes in the above code appropriately... My plan is in this LoginServlet I will check the appropriate role and enable the features in home page. Is it a right way to achieve the role based authentication ? Please guide me ...
Thanks again for your support. Have a nice week end... will catch you on Monday...
You have a lot to learn, Ganesh. I'll see what I can do, but you might want to find a good book or two. One of the better treatments of this topic I have is the Professional JSP, 2nd Edition from Wrox, but Wrox went out of business several years ago, so I don't know what a good choice that's newer is.
There is no login servlet when you control security with web.xml. The login process is done entirely by the server (Tomcat, in this particular case). The URL pattern isn't where you send stuff, it's what stuff sends you to login.
The advantage of container-managed security is it sits at the front of the webapp like a big mean dog and only lets you pass if you make it happy. There aren't any back doors, because the metaphorical house is owned by Tomcat. Like I said, that's good, since a lot of Do-It-Yourself security systems are practically nothing but back door. They assume you'll only come in through the entrance. They're wrong.
When Tomcat starts up a web application, it reads a number of items from the web.xml file and stores them in its application context for its own use. That includes the security rules, roles, URL mappings, locations of the login, loginfail and hello pages, as well as other things not interesting here.
So when you send a request to Tomcat, one of the things it does is look for security URL patterns and attempt to match the current request's URL to them.
If a match is made, Tomcat checks to see if a security context for that user has previously been established. If so, the URL request proceeds normally.
If there is a match but no security context, then Tomcat places the incoming URL request "on hold". It takes the location of the login page from the application's web.xml information and presents the login form back to the client. I'm assuming form-based logins here, of course.
The client (user) then fills in the login form and sends the login request back to Tomcat. Because this is the login form, it doesn't get sent to the web application, it gets sent to the login subsystem built into Tomcat itself. That subsystem extracts the userid and password and sends them on to the security Realm module that was configured for that webapp. The Realm allows or denies the authentication (logon request). If the request is denied, the loginfail page is displayed - it can also be a login form if you like.
If the request is authenticated, a UserPrincipal object is constructed to hold the user's security context and it's bound to the user's HttpSession object so that it will be remembered on subsequent requests. Tomcat will then retrieve the original application URL request that it had put aside ("on hold") and proceed to send it to the web application.
So, in other words, no user code does login processing, and no user code gets control at all once you've made a secured request until the user has successfully authenticated.
And, no explicit event shows that the user was just logged in. Which is why I used a servlet filter.
Servlet filters can be used to examine (and change) URL requests. In my case, I made a servlet filter that discarded the user's original URL and invoked a "home page" URL of its own choosing when the transition from un-authenticated to authenticated mode was detected. Since there's no callback to support that, I simply looked for the point when the request UserPrincipal stopped being a null object.
It's not really that hard to understand J2EE container-managed security, but the critical thing to realize is that it's a declared mechanism, not a programmed one. The primary security functions are part of Tomcat, not part of your application code. That means that you can't write a "login servlet" or callback or anything like that.
The post-login redirection is another matter. However, for that you need to understand how servlet filters are implemented.
Joined: Sep 17, 2009
Thanks for giving the deep details of container managed security. Now I got a clear idea about it. And my application is working almost 75% with a small configuration mistake.
Because of lack of knowledge on Realm settings I'm not able to get what I want.
What i have done is i have been created a folder called "protected" under root folder of my application. And kept a page named with success.jsp.
And the following is my web.xml.
<!-- Define the context-relative URL(s) to be protected -->
<!-- If you list http methods, only those methods are protected -->
<!-- Anyone with one of the listed roles may access this area -->
<!-- Security roles referenced by this web application -->
If i enter wrong credentials which are not there in ldap then it is working fine means redirecting to the error.jap. After entering the right credentials it is not redirecting or showing the success.jsp. instead of this it is showing the following error.
"HTTP Status 400 - Invalid direct reference to form login page"
I'm using Tomcat 5.5.27... Is it tomcat problem? or my configuration problem?
I'm going to make a guess and assume that you coded up a link directly to login.jsp. Or worse, yet, you're trying to login by using a URL of "login.jsp".
Because the Tomcat server takes total control of the login process, you shouldn't ever be trying to access login.jsp explicitly. When Tomcat wants it, Tomcat will find it.
If you are attempting to type in an actual URL of "login.jsp", that's your problem. Type in "success.jsp". The login will automatically be placed in front of success.jsp, success.jsp will be placed on hold while you login, and then once you're logged in the success.jsp will be pulled off hold and presented.
This is fine and works great. now my problem is, I don't know whether it is possible or not.
let us say, I'm having two roles like admin and user. ADMIN.jsp is the home page for admin role people and USER.jsp is the home page for the people who have the role called user these two pages are in a folder named "jsp".
for this what i'm doing is after login, the application will redirect to success.jsp, in this jsp i'm checking the roles and redirecting to appropriate home page.
now i'm trying to login with user role and seeing the user.jsp and in the url i'm pasting the follwoing usrl without killing the session.
http://localhost:8080/APPLICATION_NAME/jsp/ADMIN.jsp (Actually this page is for admin users only. remember i'm not loggedin with admin credentials). then i'm seeing the ADMIN page. to prevent this i made a filter which is responsible for killing the current session and redirecting to the success.jsp wheever we are trying to access the pages (any pages) using the urls like above. So my problem i.e loggedin with user credentials and seeing the admin.jsp using (url) has been resolved.
but in the url i'm seeing http://localhost:8080/protected/success.jsp only. After logged i'm trying to access the ADMIN.jsp by pasting the follwoing url without logout means without session killing. http://localhost:8080/APPLICATION_NAME/jsp/ADMIN.jsp. Now also it is redirecting me to login page through the success.jsp url. this is also because of filter. But i want to see the ADMN.jsp page using url (ofcourse after loggedin with admin role). Is it possible. the follwoing is my filter.