In Depth

Problem Solved: 3 Tales of Systems Architecture Dilemmas

Have concerns about potential vulnerabilities in your data systems? We hear from three IT security experts about how they solved the systems architecture problems that were keeping them up at night

By Joan Goodchild, Senior Editor

So, now that the DB connection info was always available to this authenticated user, we had a way to marshall what DB connections were made. Note: We stored users' roles & other security settings in the session too. Once all this front-loaded logic was done the loader would make a connection to the portal home page and use the DB configuration data from the user. The loader would build out the user specific home page & content.

Now, when the user began to interact with the system by requesting and updating data, the request would hit a "controller" code first. This code was used by the service calls to marshall the execution of all system events. It defined the specific stored procs [??] being called via a configuration file. Then by using that name value would make calls to DB layer and request the stored procs execution. The stored procs we geared to roles by setting the SQL Server users allowed to execute them. So, if the user was not in the "Item Users Group" that user would not be allowed to execute "GetActiveInventoryItems" stored proc. In SQL server 2008 you can couple #C code within a stored proc, so we marshalled the specific data fields returned based on the mapped user role. The controls on the web page were dynamically built to support the user-specific content being returned. Meaning if there was a grid of items but only two columns were allowed for, this user the control would be adjusted to that role-specific data.

If you have a problem or a solution you would like to share, email Senior Editor Joan Goodchild at jgoodchild@cxo.com

Other stories by Joan Goodchild

• Email
• Print
• Comments
• Digg This
• SlashDot

• Security Design and Architecture: Hidden Strengths
• Security Lessons from the Movies
• Security: Cover Your ASP