Deny direct access to a 3rd party application

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?

dont use another page use it in the same page as fram and enable that frame only when the user is pass authontication.

No frames are needed.

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

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

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.

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?

The purpose of connection pools is precisely *not* to have to open a connection each time one is needed.

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

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.

Sagar Rohankar wrote:
No, we're _reusing_ already opened database connection.

kk...Thanks for correcting me!

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.

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.

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.