aspose file tools*
The moose likes JSF and the fly likes Java for log in authentication? (looking for tutorial that applies to situation) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Java for log in authentication? (looking for tutorial that applies to situation)" Watch "Java for log in authentication? (looking for tutorial that applies to situation)" New topic
Author

Java for log in authentication? (looking for tutorial that applies to situation)

Matt Kohanek
Village Idiot
Ranch Hand

Joined: Apr 04, 2009
Posts: 483

Im trying to build my first site that will use log in info and saved user info. So if I have a form tag on my jsp page containing username and password and a submit button, Im guessing I need to add an action attribute to form. Something like this:



I am just unsure what the java code will look like that goes about authenticating. I should mention the users will be stored in a web service, something similar to this:



So the java code will need to first make sure the username is located in the web service, somewhere between the <userName> tag, and then check what is between the <password> tag for that specific user. I'm unsure even where to start here, and I have been trying to look at login tutorials but there are so many different versions Im not sure which applies to my situation.

So if anyone knows a good tutorial that applies to this or if someone just wants to give me adviuce on what the java code looks like that would be great.

Thanks

ps - My next problem will be figuring out how my web site will know what user data to load up depending on which user logs in. Each entry in the web service will have foreign keys <FK> For example, say user xyz creates project x. Project x will look like:



or somethign similar. I can almost imagine how this will work, but any tips would be great as well before I get that far


True wisdom is in knowing you know nothing - Socrates
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19693
    
  20

Moving to the JSP forum.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61198
    
  66

Why the #{} ? Are you using JSF?


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Matt Kohanek
Village Idiot
Ranch Hand

Joined: Apr 04, 2009
Posts: 483

Yes, but since my question is pertaining to the java code that is why I put it in the java forums. The jsf snippet was just to illustrate what I am doing, does this really belong in the jsp forums? I read through my post again, the question I have really doesnt pertain to jsp or jsf does it?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16055
    
  21

Bear Bibeault wrote:Why the #{} ? Are you using JSF?


You can use EL in JSPs these days. It's not just for JSF. However, EL won't work on container-provided pages like login forms.

Matt:

I STRONGLY recommend that you don't write your own login code. I know everyone does it, but nobody does it right. Use container-based security.

http://www.mousetech.com/blog/?p=11


Customer surveys are for companies who didn't pay proper attention to begin with.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61198
    
  66

Tim Holloway wrote:You can use EL in JSPs these days.

In JSP, the notation is ${} not #{}.

Tim Holloway wrote:I STRONGLY recommend that you don't write your own login code. I know everyone does it, but nobody does it right. Use container-based security.

I will respectfully disagree. I've always found container-based authentication woefully inadequate for my needs.

Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61198
    
  66

So is your question really about how to parse the XML coming in from the web service?
Matt Kohanek
Village Idiot
Ranch Hand

Joined: Apr 04, 2009
Posts: 483

No, I already have the objects written for serialization and deserialization (simplexml). I'm just not sure how to write the java method that will authenticate if the uid and password are valid AND that the password is correct for that specific user. I'm guessing it will be something like
if (status code != error) {
return success;
}
and then Ill have a navigation rule that takes a user to the projects page upon "success"
But as I said I have no experience at all with this aspect of coding. Im creating a site where users will login and access projects they have created. Thats why I said in the poriginal post I was really looking for a tutorial that fits this situation, because I really don't know where to start, and I found so many different types of log in tutorials I wasnt sure which of them applied. I know that is a lot to ask for someone else to go out and find the tutorial I need, I was just hoping to catch someone who knew of one right off the bat.
If there is something out there to automate most of this which is what Tim seemed to be implying that is fine for me. It doesnt even have to be hacker proof. This is a project I won from a company while Im still in school, so they know that my knowledge is still pretty limited. It is something they will eventually use for their customer website, and Im only working on a small part of the project (about 1/4 of it). The company does this as an opportunity for top performing MIS students at the college I go to.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16055
    
  21

Bear Bibeault wrote:So is your question really about how to parse the XML coming in from the web service?


Non sequitur

The "#{}" (lvalue) form is part of the Unified EL (JSR-245). I suppose it has no actual special utility outside of frameworks like JSF that support read/write references, but it can be used in on a JSP these days.

What doesn't container-based authentication not give you? I've done some extremely complex apps and not had to write my own A&A system. I've got one now that even does post-login processing.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16055
    
  21

Matt Kohanek wrote:
and then Ill have a navigation rule that takes a user to the projects page upon "success"


That just bounced you firmly back into the JSF world. It doesn't apply to raw JSPs.

It also illustrates the #1 failure point of most DIY security systems. They assume that the only way to get to that projects page is by being navigated to from a login routine. A lot of times I can do a direct URL request and bypass the security system entirely. Even in cases where there's session data that would have been set by the login code, there are ways to jam in bogus data. One of the strengths of container-managed security is it cares less about where you're coming FROM than what you're trying to get TO! So it guards the doors. A lot of improper requests are blocked by the server itself before they have a chance to weasel their way into the application.

I have a friend who used to be an EDP auditor for a fairly large bank. People HATED him, because he got paid to shred their clever security code.

Matt Kohanek
Village Idiot
Ranch Hand

Joined: Apr 04, 2009
Posts: 483

From what Ive seen this seems like the tutorial that I most need:

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html#wp303355
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16055
    
  21

Matt Kohanek wrote:From what Ive seen this seems like the tutorial that I most need:

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html#wp303355


Up to a point. These are instructions relative to one of Sun's own J2EE appservers and in regard to creating your own security realm implementation. You should be able to trust whatever it says about setting up authentication, roles, and URL/role mapping in the web.xml file, but I'm dnot so sure about the deployment instructions. There is a deployment standard (JSR-88). but if there's a universal deployment tool now available, I don't know about it.

For Tomcat, you can define a Realm in the web application Context. Tomcat has a set of predefined realms that are good for most applications. The MemoryRealm is a good one to use for app testing. Which brings up another item on the list: since J2EE container security is imposed from without via a standard interface, your test security system doesn't have to be the same as the production one will be. I used to use MemoryRealm to test apps that would be in production using Active Directory Authentication and Authorization, because getting mods into the Active Directory security rules was a slow and tedious process.

Here's a much better URL for you:

http://www.oxxus.net/tutorials/tomcat/security-realms.htm
Matt Kohanek
Village Idiot
Ranch Hand

Joined: Apr 04, 2009
Posts: 483

That looks very promising, thanks.

Although Im not totally sure it will work for my situation. The web service that stores user info and that I dont have control over is already in place. It has the format I mentioned earlier:



So I am going to have a log in page with a user and password field, plus a submit button of course. There will be a managedBean to link the fields to my java code. Let's say the fields are userBean.userName and userBean.userPassword. I also know that if a user is listed there in the web service, it returns something like this:



So if I am correct, I think I will need some java code something like this:



The submit button from above will call this method. Then Ill have a navigation rule that directs to the next page upon "success". I think this should work, although I have not been able to test any of this because I am at work right now. But it seems logical. I am just unsure how I will have my java source code check for if(code==200). I dont know how the java code will be able to check this element from the web service, although Im sure if I look into it I can get an answer.

Please let me know if this should work if you have time to look it over, and also if I am off somewhere, or if there is a better way.

Thanks
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16055
    
  21

Oh. that makes it totally different. You have a custom authentication backend. I missed that.

When you use the Container+web.xml for security management, the signon process is done externally. Your app nevers see the user ID or password. In fact, you never actually get notified when you've been logged in. When the app container detects a need for an authenticated user, regardless of where you are in the app, it does this:

1. Puts the current page request on hold
2. Presents the login page that you defined in web.xml (assuming form-based logins)
3. Reads the userId and password from the login form
4. Passes them to the security Realm and gets back a go/no-go indication.

If the authentication succeeds, a UserPrincipal object gets constructed and attached to your HttpServletRequest and the derailed page request is resumed. If the authentication fails, the loginfail page is displayed and the process repeats until the user logs in successfully or gives up.

The actual login code is part of the security Realm, which is server-dependent. It's not difficult to write a security Realm package, but the Realm isn't part of the webapp (it is, after all, CONTAINER managed security). In your case, you'd have to have a custom Realm that invoked the web service. The Realm classes have to be places in the Tomcat server classpath (NOT in the application WAR), and the server.xml file has to be customized to define the custom Realm. I've done this for a web service, but security code is less forgiving than application code and when you start talking about customizing the server itself, sometimes people get a little excited. So you may just have to do this the hard way.

In a shop that's truly dedicated to security, a custom security Realm would be a good investment. However, few shops are dedicated to security, as you may have noticed in the headlines over the last several years. To get much of the same benefits of container-managed security without modifying the server, you can create a servlet filter to scan for protected URLs just like the container does. The difference here is that filters generally don't intercept and restart URL requests, you have to write and debug your own security code - including the interceptor code - and the security settings in web.xml aren't used.

The most common approach of all, alas, is where "code toads" put security code directly into the application logic itself. Except when they forget to. Or someone comes along later and changes things and doesn't understand how the security code worked. Because the security system is a one-off job that's not documented in a book down at the local Barnes&Noble. Or the security system gets changed and suddenly 47 separate and widely-disconnected parts of the application all break at once. Well, actually, it was 48, but no one will know that until December. And this lovely state of affairs is probably what you're going to get stuck doing unless you happen to work in a place where someone like me takes exception and sets up a proper security realm (and has the clout to get it made part of the shop standards).

A "code toad", BTW is someone hired to be cheap, not good who, can produce many lines-of-code very fast (because lines-of-code are things that bean counters can appreciate). As opposed to fewer, more efficient, more reliable (and more secure) lines of code. Not all DIY security is done by code toads, but code toads don't know any other way to do things. Otherwise they wouldn't be code toads. And there are a lot of code toads out there.

Just one final comment. Its VERY bad practice to have a security server send out the password to the security client. Even when the password's encrypted. And, in fact, a whole security paradigm revolves around passwords that can't be decrypted (one-way encryption). Best practice is that the client establishes a secure, encrypted channel to the server and sends the credentials to the security server, which then securely accepts/rejects them. In the Tomcat JDBC and DataSource security realms, they can hash the password and do a "SELECT COUNT(*) FROM user WHERE user_id = ? AND password = ?", where the hashed password is stored in the database. If the returned count is 1, the user passed. If 0, the signon failed. If > 1, someone needs to take a look at the database. That way, the password is never seen in plain text inside the database or returned to the webapp server.
Matt Kohanek
Village Idiot
Ranch Hand

Joined: Apr 04, 2009
Posts: 483

Thanks for the useful comments Tim.

This site will eventually be a customer website for this company, but it is in its first iteration, so the part I am developing now doesnt have much focus on the actual security. Im just needing to establish differnt user accounts so different entities will be loaded depending on who is logged in. Im sure later down the line better security will be implemented, but my part in this will be over by then.

I will keep in mind your tips though, thanks for taking time with it.

I may have more questions on this as I get into the coding for it, so I will just use this thread to post them unless totally unrelated.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16055
    
  21

Regrettably, usually whatever "good enough" security system goes into the first pass of a system often scars it for life. There's an old mainframe acronym - PTF which the cynical have refactored to mean "Pemanent Temporary Fix".

One of the biggest reasons I like container-based security is that relatively little security is actually coded in the program. So when security changes, it's mostly just configuration parameters. It's much easier and safer than modifying working program code.

I'll leave you with a final meditation. Authentication and authorization are two separate things, even though they're both essential parts of a good security system. Likewise, authentication and identity are distinct concepts. My own experience using database for authentication has led me to prefer keeping the userid/password table separate from the account-related data table. I use the userId (held in the J2EE Principal) to cross-reference for user account information, but otherwise the two subsystems don't intersect. With less cross-coupling, the application architecture is a little cleaner, and thus less work (time=money) to maintain.

Also, don't feel obligated to continue in this thread. We prefer not to have threads ramble (sort of our own version of limited cross-coupling). Everything I've discussed up to now has been true for JSP-only architecture, Struts, and JSF. However JSF does have its own security quirks, which are best addressed in the JSF forum.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java for log in authentication? (looking for tutorial that applies to situation)