This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Servlets and the fly likes Deny direct access to a 3rd party application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Deny direct access to a 3rd party application" Watch "Deny direct access to a 3rd party application" New topic
Author

Deny direct access to a 3rd party application

Tristan Steiner
Greenhorn

Joined: Aug 24, 2012
Posts: 1
Hi,

I have an application hosted on app.myHost.com

Because I only want to allow authorized users to access this page I created a page auth.myHost.com that does all the user/password checks.

Once a user is authorized he gets redirected to app.myHost.com

Problem: How to prevent direct access to app.myHost.com - and allow only redirects?
Jagdish Hatagale
Ranch Hand

Joined: Apr 07, 2010
Posts: 33
dont use another page use it in the same page as fram and enable that frame only when the user is pass authontication.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61092
    
  66

No frames are needed.

Use a servlet filter to authenticate each request that comes in.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
vipul bondugula
Ranch Hand

Joined: Oct 14, 2010
Posts: 218
Bear Bibeault wrote:No frames are needed.

Use a servlet filter to authenticate each request that comes in.


Suppose authentication is done against database , i mean every time in the filter : open a db connection and check the credentials against database. Then, based on the response allow/disallow user.

Is database connection opening is a better approach in filter.?

Thanks
Vipul


Thanks
Vipul Kumar
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41599
    
  55
The usual approach to DB connection handling in a web app is a connection pool. That's irrespective of whether it's done in a servlet or a filter.


Ping & DNS - my free Android networking tools app
vipul bondugula
Ranch Hand

Joined: Oct 14, 2010
Posts: 218
Yeah , ok. Whatever it is connection pool (or) direct database connection, for each request we have to open a connection to check user authentication.That will be a performance blow, right?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41599
    
  55
The purpose of connection pools is precisely *not* to have to open a connection each time one is needed.
vipul bondugula
Ranch Hand

Joined: Oct 14, 2010
Posts: 218
In software engineering, a connection pool is a cache of database connections maintained so that the connections can be reused when future requests to the database are required.


According to the definition, database connections are reused using cnnnection pool. This is precise that we open a database connection for each request done.

Thanks
Vipul
Sagar Rohankar
Ranch Hand

Joined: Feb 19, 2008
Posts: 2902
    
    1

vipul bondugula wrote:
In software engineering, a connection pool is a cache of database connections maintained so that the connections can be reused when future requests to the database are required.

According to the definition, database connections are reused using cnnnection pool. This is precise that we open a database connection for each request done.

No, we're _reusing_ already opened database connection.


[LEARNING bLOG] | [Freelance Web Designer] | [and "Rohan" is part of my surname]
vipul bondugula
Ranch Hand

Joined: Oct 14, 2010
Posts: 218
Sagar Rohankar wrote:
No, we're _reusing_ already opened database connection.


kk...Thanks for correcting me!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

The technical term for user-defined security systems is "hacked".

This is not a joke.

When I first started working with J2EE, JSPs hadn't even been invented. I've worked with it almost daily ever since. I've seen banking systems, I've seen investment systems, I've even seen a military system or two.

And every last bloody one of them that did their own security had holes that an unskilled person could drive through in 15 minutes or less.

J2EE has a perfectly good security system that can block requests before they can even reach the application. It was designed by people who were formally trained in security and didn't have to do security as "just one more job" because is was their job.

And the beauty of it is that the amount of actual code you have to write (and therefore debug) is minimal, because the security is applied from the outside.

If you absolutely must implement your own security code, a servlet filter is one of the preferred ways to do it. But it's a poor second to having the server itself on your side. I should point out however, that all this noise about database connections is immaterial. Unless you want to force the user to log in on each and every request (and don't forget, images, css, and javascript are also secured requests, unless you punch holes in your security screen), then you should be establishing a session and keeping the login status there.


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: 61092
    
  66

Tim, do you know of a good resource that the average developer can use to implement container-managed security? I think the problem is that for all but the more senior developers, the resources I have seen do not do a good job of explaining how to set up security for various requirements. So it's usually easier for people to just roll their own.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

Good point, Bear. Maybe we need a forum or a wiki or something.

Container security comes in 2 parts. One part is the Realm, which is part of the server. I think this is the part that most people have trouble with. All a Realm really is, however, is a mechanism that can answer 2 basic questions: 1) is a given set of credentials (userid/password) valid? 2) does the user participate in security role "X"? The hard part is attaching that mechanism to whatever service, database, LDAP server, or whatever is used to assist in answering those 2 questions.

In the application itself, virtually any basic J2EE book covers setting up secure transport, and since that mechanism is intimately intertwined with the container security definitions, usually there's some light mention of security roles as well. Unfortunately, they then ruin it by following up with an example using user-defined security.

Put simply, if you map a URL pattern for security, you can attach one or more roles to that URL pattern in the web.xml file. If a client (not yet logged in) requests that URL, the server will sidetrack the URL request, present a login screen, run it against the Realm, and then (assuming valid identification) resume the interrupted request, having built a security context (UserPrincipal) and attaching it (as well as its userID) to the incoming HTTPURLRequest object. All further incoming requests will likewise be decorated until a logout is done (via timeout or via session.invalidate()).

Although I said the incoming secured URL will be resumed, that's not totally true. The allowable roles mapped to that URL pattern are checked against the roles allotted to that user. If there's a match, the URL is dispatched. Otherwise the server rejects it. It never reaches the application or any user code or other resources. In other words, it's a declarative security mechanism.

Sometimes there's a need for determining rights within application logic. A classic example of mine is where a resource displays a web form for both data-entry personnel and for auditors. I can limit the form display and update requests to those 2 roles, but auditors are further restricted to a look-dont-touch role. In such a case, I can do things like attach "read-only" attributes to display elements based on roles using the request.isUserInRole() method and I can fine-tune actual update attempts similarly.

There's really not much more than that. For full-stack J2EE servers, the system also propagates into things like EJBs, which have their own equivalent running from the same framework, but once you know the basics, it's quite simple.

"Simpler" is no excuse for user-defined security, I'm afraid. The Internet is an ugly place these days and a security system is no stronger than its weakest link.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Deny direct access to a 3rd party application