Weaving WebSphere: Web Application Security

[MCWebsite.Staff]

** This thread discusses the article: Weaving WebSphere: Web Application Security **
** This thread discusses the Content article: Weaving WebSphere: Web Application Security **
0

[Guest.Visitor]

Weaving WebSphere: Web Application Security

** This thread discusses the article: Weaving WebSphere: Web Application Security **
Joe, you say 'If you limit database access to your server applications'. What do you have in mind here? Stored procedures?

[J.Pluta]

Weaving WebSphere: Web Application Security

** This thread discusses the article: Weaving WebSphere: Web Application Security **
Well, stored procedures are one technique. Not my favorite, for a number of reasons, but definitely a significant improvement over direct access to files and fields. Other options include things like data queues or remote program/procedure calls, both of which are quite easy using IBM's Java Toolbox. Heck, if you design properly to minimize the overhead, you might even use a web service. The point is that as long as the interface between the client and the server is not tied directly to the layout of the database, then you can effect whatever changes you need in the database layer completely tranparently to the client. Joe

[Guest.Visitor]

Weaving WebSphere: Web Application Security

** This thread discusses the article: Weaving WebSphere: Web Application Security **
Hi Joe, What are your issues with Stored Procs? I think the answer is that if you have a 5 screen web UI application, you need several stored procs with rigid parms to handle the screen data and edits. With your data queue technique, it's just a giant stream of bytes that can be carved up using external data structures, and easily adapts to future needs. Let me know. Thanks. Chris

[J.Pluta]

Weaving WebSphere: Web Application Security

** This thread discusses the article: Weaving WebSphere: Web Application Security **
Hi Chris! Yeah, the rather rigid nature of stored procedures makes them cumbersome to me. I have grown VERY fond over the years of using a bidirectional data structure to pass data between two machines. Depending on the situation, I might use a fixed-length structure or a variable length structure; the latter just takes a little extra plumbing. But the simplicity of a fixed structure is often worth the overhead; 2000 bytes requires 160 microseconds to transfer on a 100MBit LAN, and that drops to 16 microseconds on a 1GB connection. But that's not the only problem. Stored procedures have all the baggage of ODBC. For example, at some point the client has to specify "UID=myname;PWD=mypassword" in the clear. I don't care how or where it happens, at some point that user ID and password is in variables on the client, and by the nature of ODBC these have to be real, valid i5/OS user profiles. I hate having i5/OS user profiles and passwords in the wild. They can then be used for other things. If I use a web application server, I can use web user IDs (for example, authenticated by some standard Apache mechanism) and then translate those to a user profile under my control. End users never see the user profile or password. I can do the same with a good client/server approach, by reading a socket and then performing my own authentication against a validation list. Anyway, stored procedures have their benefits. Lots of people understand them. At the same time, those very benefits can make them more susceptible from a security standpoint, and as you point out, stored procedures are not very flexible either. Joe

[nandelin]

Weaving WebSphere: Web Application Security

** This thread discusses the article: Weaving WebSphere: Web Application Security **
This is a very good article, Joe. You've only exposed the tip of the iceberg, though. Web applications may run under various environments (development, evaluation, production, etc.) where certain users may only be authorized to certain environments. Different environments may even contain different versions of the applications. Administrators may want to enable certain environments only during certain days, or during certain hours of the day. Different users may be authorized to different client data libraries or different physical file members if client data is stored in different physical file members. Different users may be authorized to data pertaining to different fiscal years, where fiscal year data may be stored in different libraries or physical file members. Web applications may need to be accessible on different domain names, where say one domain may be accessible only from a local area network, while another domain may be accessible from the Internet, where certain users may be authorized to one domain, but not another. Web applications may need to be accessible from only a menuing system, with no option of book marking the entry point, or any other point within the application, where certain users are only authorized to certain menus, or only authorized to certain items on the menu. Web applications may need to expose different functionality, depending on which menu item it was bound to when the application was launched, or when a user accessed the application for the first time. When sessions expire, users may need to be automatically redirected by to the menu. Certain users may only be authorized to certain records in a table, or certain fields in a record. Certain users may be able to view records pertaining to one fiscal year, location code, client, or whatever, but able to update records for another fiscal year, location code, client, or whatever. The mechanics of "authorization" may need to be easily configurable. I'm glad you touched on the problem of ODBC, which is essentially based on the premise that security is secondary to accessibility. If users need to query and manipulate data via ODBC, then how about providing export capabilities in applications, where users can only export data to their PC that they're authorized to? The ODBC problem is compounded when talking about environments supporting software as a service, where applications are hosted on a single server, but support many different companies, where each company needs to be secure. ODBC connections require quite a bit of overhead too, especially is situations where applications are querying security configuration files to know whether the current user has authority to a hyperlink, or authority to a record, field, or whatever. Nathan.