Am Donnerstag, 16. Januar 2003 13:52 schrieb John Smith: > I'm sorry if this is rather a basic question for the list,
Not too basic, as security is alway complex. > but I am just > getting started using JSP to front-end an Oracle server. I can > successfully connect to the database and produce HTML pages full of data, > but before I can make any real use of this I have to implement security. > What I think that I want is to have the user provide a name and password, > which is then used to establish a connection to Oracle from a connection > pool. As we're talking about a web app here and the credentials are sent in clear text, first of all, I'd make sure the connection is encrypted, that is, using SSL and HTTPS instead of HTTP. > This connection needs to time-out on inactivity or when the browser > closes, causing any subsequent attempt to load a page to be re-directed to > the login page. The only way to get aware of a session having ended is by either getting notified by the user (by explicitly logging out) or timeouts. You can check if a request already belongs to a session by calling HTTPRequest.getSession(false). This will either return the Session the request belongs to, or null if there is no session yet. In case of the latter, your FrontController would forward the request to the login page, and so on. > Any comments or suggestions of things I may not have > thought of appreciated. Well, considering connection pools: pooled connections do have the advantage of improving speed, but at the cost of losing granularity when it comes to user rights on the database tier. With connection pools, it's possible to group users into different categories, i.e. maintaining different connection pools for diffe- rent classes of users. What AFAIK is not really possible is to make use of a connection pool on the one hand and still control user rights the same way Oracle does on the other hand. Well, of course you could implement a connection pool for each individual user, but what real sense would that make? In the end, you'll have decide for yourself what may still be tolerable regarding security concerns, and what is not. One thing that may help you on the backend is to prevent direct access to the table owner's schema. Instead, you could have different 'users' for each group, accessing the table owner's objects indirectly, either via synonyms or even (usually read-only, yet (if coding against Oracle) even updatable) database views. If you're *really* into Oracle and use Designer for ERM, you could even extend this to Table API, replacing direct SQL access by Oracle packages. Still, one general problem remains: in the end, the web (or J2EE tier) has to make an Oracle connection, providing the necessary credentials (user/password, LDAP, NDS and so on) and thus being authenticated. What you may do in Oracle entirely depends on this critical point. If you put Oracle connections in a pool, which in most cases definitely is a good choice, each 'pool' user finally has the same rights as each other one in the group on the back end objects. In most cases, not really much to worry about. Still, be aware of that point. > I have found all of the bits that appear to be required, but am unsure how > to hang them together. Surely this must be a fairly common requirement and > has been done before? Can anyone direct me to a resource where I can find > a complete set of pages, beans etc that I can then start customising rather > than have to re-invent it from scratch? otn.oracle.com, for example. > Thanks for any help. > John HTH, -- Chris (SCPJ2) ------------------------------------------------------- ==========================================================================To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
