The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Where do you think security belongs?

So, I was discussing where to put security code (user x can edit project y and see project z) in a new web app with a coworker. It got me thinking -- is security like this an application/framework function, or a business function? If we're talking MVC, would it go directly IN the model, or in the glue that relates a model to the controller?

I'm assuming this isn't a black and white issue, so I'm curious what other people think.

In this context, I think we're going with the application/framework method -- in the domain model, a project doesn't need to know who can edit it, only the application needs to enforce that.
PeterL Send private email
Monday, June 25, 2007
 
 
Security is a cross-cutting concern in the system. It needs to be implemented at every request endpoint.

From a requirement perspective, security is a non-functional requirement. However it is a business requirement. (we don't implement which is not required by the business, right?).
Dino Send private email
Monday, June 25, 2007
 
 
"Security" is a very broad topic so you need to be more specific.

The first round of discussion usually centers around the topics of "authentication" and "authorization". You aren't really being clear about which one (or both) that you are talking about.

But I would personally argue that "security" will probably end up in many different layers. After all, security can include the above topics as well as others such as encryption/decryption, key management, input validation, data masking, user impersonation, database connection accounts, secure application logging, SQL injection, buffer overflows, secure configuration management, and much more. These topics will inevitably touch each and every layer of your application.
unknown
Monday, June 25, 2007
 
 
Whether it "belongs" there or not, I tend toward security at the database level. Keeps it simple for the types of apps that I write. The business objects don't have to know who can do what and who can access what data. The UI doesn't have to know it either. If they go after the data, or they try some operation that they aren't authorized for, then the database layer returns a "Sorry! Can't do that." error.

Some folks like it higher up in the stack but for me that's a waste. There may be several, or dozens of apps trying to hit the data. Putting it in the database means that whatever app is going after the data, there's only one place we manage the security. In the database. It's simple and neat and tight.

Most of our apps are basic database CRUD and reporting, though. Other types of apps it might be a better fit elsewhere, but the database works well for us.
Sgt.Sausage
Monday, June 25, 2007
 
 
Sorry, I'm talking authorization. Authentication is taking care of, as mentioned, at request endpoints.

Thanks for the replies. It's given me a few different ways of thinking about it.

Monday, June 25, 2007
 
 
"The UI doesn't have to know it either."

In some cases it does. One case was "masking data". For example, only managers should be allowed to see the salaries, phone numbers, and SSN's of employees. But the database shouldn't restrict someone else from seeing the rest of the record just because they can't see one piece of the data in the database. So the UI may need to change based on who is using the system. And this "change" may also include the addition or removal of functionality as well. For example, the "hire new employee" link on a page may not be shown for someone who does not have the proper clearance to perform that function.
unknown
Monday, June 25, 2007
 
 
One more thing I'll point out is that it is best to have security in multiple places instead of relying on one place.

One issue that occurs often is "broken authentication and authorization". This happens when developers assume that the user will be accessing the application through the interface provided. In my previous post I talked about a link to a function for "hiring a new employee" that might not show if the user doesn't have the proper clearance. But that doesn't mean the user couldn't potentially get to that function anyway through other means. For a web app, the user might bypass UI security by requesting URL's directly. If the only security that exists is in the UI then the user has foiled the security system because they aren't forced to use your UI to begin with. In this case, having secondary security systems in the database helps protect you. Think "defense in depth".

You should also consider googling for "payment application best practices" and reading the resulting PDF document put out by the payment card industry to find out more about the types of security problems you need to watch out for. It isn't an exhaustive list but it is a good start. Most of the issues I presented in my very first post are from that document.
unknown
Monday, June 25, 2007
 
 
"In some cases it does. One case was "masking data". For example, only managers should be allowed to see the salaries, phone numbers, and SSN's of employees. But the database shouldn't restrict someone else from seeing the rest of the record just because they can't see one piece of the data in the database. So the UI may need to change based on who is using the system."

Actually, this is one of the places where you *DON'T* want to pass it to the UI and let it handle the scrubbing.  The controller should only allow the correct subset of data to be passed along to the View.  The benefit of this approach is that once you start approaching the system from a different UI perspective - think Web Service instead of Web Page) - you already have a safe data set to work with.
KC Send private email
Monday, June 25, 2007
 
 
"... After all, security can include the above topics [authentication and authorization] as well as others such as encryption/decryption, key management, input validation, data masking, user impersonation, database connection accounts, secure application logging, SQL injection, buffer overflows, secure configuration management, and much more."

Agreed. Each of the above occurs at a request endpoint. The type of request determines the required security handling. However your mileage may vary. Security needs are different depending on how the system deploys.

1) 2) & 3) are totally different from a security perspective, even if they do the same thing.
1) Browser --WAN--FW- WebServer -FW--LAN-- AppServer --LAN -- DBServer
1a) Browser --WAN--FW- WebServer --LAN -- DBServer
2) RichClient --LAN-- DBServer
3) Application (embedded database).

1) Has request endpoints in 2 FW, Webserver, AppServer and the DBServer.
1a) Has request endpoints in 1 FW, Webserver and DBServer.
2) Has request endpoints in the rich client UI and DB server.
3) Has request endpoints only in the App UI.
Dino Send private email
Monday, June 25, 2007
 
 
> Whether it "belongs" there or not, I tend toward security at the database level.

This is unusual for web applications for several reasons including the fact that it typically prevents the app from using database connection pooling, which can seriously degrade performance. 

More common is a "trusted subsystem" model, where the application's DAL has an application-specific database login, and the application is trusted to properly authenticate its users.

IMHO authentication logic should normally be in the BLL layer.  The UI may duplicate the authentication logic (e.g. hide UI elements that the current user is not allowed to use), but should not be trusted to always get it right.
Joe
Monday, June 25, 2007
 
 
Security belongs into the design phase of the application. Reality tells us that security WILL fail when it is treated as an add-on. Furthermore, it is not a function (though finally implemented in functions), it is a process, not a product.

That said you should answer this question first: What are the typical threats that you need to protect your application against?

If this goes too far beyond your question and you are only interested in your specific problem "(user x can edit project y and see project z)", then you should not use the broad term "security" and be more specific instead, eg. talk about "access control". You don't ask "How to design a GUI" when all you need to know is how to use a listbox, do you?
Secure
Tuesday, June 26, 2007
 
 
I think that Secure said it well.

Security (as in being secure) is an emergent property.  It is like where the quality of a T-shirt comes from.

You can point at reflections of quality (the material used, the stitching, etc.), but that is not actually the quality.  You can not easily take a low-quality T-shirt and make it into a high-quality T-shirt, because quality permeates the item.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Tuesday, June 26, 2007
 
 
Looking back at my subject, I realize that it didn't come across the way I wanted it to. It should have been "Where you think authorization and access control belongs?". -security- belongs everywhere in the app. Totally agree.

Tuesday, June 26, 2007
 
 
Playing the devil's advocate, I'm going to disagree.

Ideally yes, an application should be secure everywhere. However, that comes with an actual economic cost, either in terms of the resources needed to implement it, maintain it or execute it. And there will be situations where something sounds like a good idea on paper but is too expensive in practice.

For example, people have suggested securing the software system at the database layer in the event that people try to access it outside of the web application. Done improperly, that actually increases the cost of a query. One alternative is to use a firewall that simply blocks any requests not coming from the web server.

Another example is that the value of the data may not warrant the additional security. I would hope you use stringent practices if you're handing my medical records. If you're maintaining a basic forum web site for comic book collectors and you just want to keep track of who posted what, I'm perfectly fine with you simply wiping the site and restoring from backup whenever anyone hacked into it.

As others have said, security is a process. I'm also saying that one aspect of the process is identifying your risks and determining what is an appropriate response to that risk given your budget, resources, business goals, etc etc. And there will be cases where no security is needed.

To answer the original question, in most corporate IT shops, I would simply do authentication/authorization in the controller and log all inserts, updates and deletes at the database level (use the database's built in features if you can rather than rolling your own).
TheDavid
Tuesday, June 26, 2007
 
 
Security belongs at each interface that may be exposed to the outside world.  Obviously, the UI needs security - an initial log on, data validation and text restrictions to prevent overflows and other nasties, timeouts and other mechanisms to prevent access to an expired page.  Anything that has an internet connection needs security against malformed packets.  Database connections need to be secured, especially always active pooled connections.  Audit logs should be provided at each level.  Depending upon how broad of a definition of security that you want to use, there are many other considerations.
Wayne M.
Wednesday, June 27, 2007
 
 
I always insist that secured operations - anything one user can do and another cannot - are enforced in the busines model layer of the application. And I allow duplication to improve the user experience up to the project's tolerance for the usual pain of duplication. For example, the UI is allowed to disable a button the user cannot use, but the business layer cannot trust the UI to disable the button, and is required to check again.

I've never been able to use the database for any of this because the kind of enterprise integration apps I work on hit many databases, web services, message queues, etc.

As far as where the authorization interface sits in the architecture, it's probably one of those utilities that cuts across all layers.

if ( SecurityThing.authorized( user, action ) ) ...
Stan James Send private email
Wednesday, June 27, 2007
 
 
For Java, you may use JAAS for authorization & access control.
Dino Send private email
Wednesday, June 27, 2007
 
 
I'm with Stan.  Who can do what is a business layer issue and that should be the authoritative source.  If the UI needs to hide things for usability, that's fine, but that's a usability issue.  If the UI guy screws up and shows someone a menu item they're not supposed to have, it's going to throw an Exception anyways.

I'm also a fan of trying to think of ways to not implement my security rules twice.  So, I like to have an "Am I authorized to do this?" method that is exposed from the business layer.  The business layer itself will use this method for authorization processing and the UI can use it if it wishes for UI tweaking.
JSmith Send private email
Sunday, July 01, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz