I am working on a project with very detailed security requirements. I would honestly not be surprised if the model proposed was as complex as for any intelligence/security agency. Now I've read that incorporating security with business logic is a mixing of concerns and thus a practice to be avoided.
However, all attempts at abstracting security have either failed or created "abstractions" as messy as before. Is it possible for security to be so specific that it becomes part of business rules? In some situations violating security, only masks the data, whereas in other situations will terminate the session, and at others time it will trigger default values to be used instead. The are many requirements that respond to security priveleges.
My fundamental question is: could I be in an exceptional case (i.e. one where incorporating security is sound) or am I not understanding something fundamental about abstracting security?
Edit:
tl;dr (of answers as I understand them): authentication (who are you) is very much a cross cutting concern and should be abstracted, whereas authorization (what can you do) is business logic. Lacking that vocabulary and having only the term "security" (or perhaps failing to appreciate the distinction between the two) lead to my confusion.
Security is split into two parts; authentication and authorization. Authentication is a pretty specific use case. How do you determine that a user is trusted out of a set of untrusted users. I think this is cross cutting; you need to keep unauthenticated users out of your system, or a subset of your system.
Authorization (can the user do something) is very much a business rule. It can (and often is) very specific and different to each use case. Who determines what roles can do what? Well, the business does. No one else can answer that for you.
In the Csla.Net 4 framework, that's exactly how authorization is treated; as a specialized business rule. You're not even limited to "user is in role" or "user has permission." You can make more complex rules "user can edit this field if workflow step has not past this particular step."
I suppose an exceptional case would be if your business logic IS security services of some kind then yes. However I think your problem may be that you are confusing user authorization with authentication.
Certainly Authentication should have a set of rules associated with it but the end result should be, identification of the user and creation of the session.
Authorization would be seperate from that where we determine the user role, and what privileges are laid out by that role.
A typical example would be that Authentication returns a User object and stores it in session. The User has 1 to many roles. A role may have 1 to many privileges. A business logic method might be sendEmail. This method queries the User object for a specific privilege, if it exists do something, if not do something else.
EDIT: Security in my opinion should always be a cross cutting concern when it comes to the user, however if your business logic involves properties of objects that are not the user, CRUD of those objects, or administering other users then it falls in line with your business requirements and thus is Business Logic.
Related
Our users create orders via an external online platform. This online platform sends our API any orders created by our users. How can we safely ensure that these orders were created by the user the online platform says?
We are investigating sending an authentication challenge for each order received via email/sms. This could become tiresome for operators creating orders all day though. What is the ideal pattern?
Security, including non-repudiation concerns, is a question of striking a balance between safety and convenience. The more secure you make a system, the more inconvenient it becomes, and vice versa.
A sufficiently secure system could be so inconvenient that it scares away users. Thus, security analysis and threat modelling should involve both technical and business stakeholders. Making a maximally secure system that no-one wants to use solves no problems if your company goes out of business from lack of customers.
The OP concern about order verification via email or SMS is a good example of this conundrum.
Specifically regarding order verification, you might consider a 'batching' feature where super users can create batches of orders that they only have to verify with a single SMS or email.
The disadvantage of that idea is that you run the risk of users misunderstanding how the feature works. If it's unclear to users that they have to submit the batch at the end of the working day, they may believe that they've submitted many orders, where in fact, they've submitted none.
This strikes me as mostly a UX problem, more than a technical problem.
Another option is to ask each user to sign their orders using PKI. Users should sign with their private key, but this again becomes a usability and infrastructure challenge.
Work with all stakeholders to find an acceptable solution that solves the right problems.
Since the most similar questions are related to ASP MVC I want to know some common right choice strategies.
Lets try to decide, will it go into the business layer or sit on the service layer.
Considering service layer to have a classical remote facade interface it seems to be essential just to land permission checks here as the user object instance is always here (the service session is bound to the user) and ready for .hasPermission(...) calls. But that looks like a business logic leak.
In the different approach with an implementation of security checks in the business layer we pollute domain object interfaces with 'security token' arguments and similar things.
Any suggestions how to overcome this tradeoff or maybe you know the only true solution?
I think the answer to this question is complex and worth a bit of thought early on. Here are some guidelines.
The service layer is a good place for:
Is a page public or only open to registered users?
Does this page require a user of a specific role?
Authentication process including converting tokens to an internal representation of users.
Network checks such as IP and spam filters.
The business layer is a good place for:
Does this particular user have access to the requested record? For example, a user should have access to their profile but not someone else's profile.
Auditing of requests. The business layer is in the best situation to describe the specifics about requests because protocol and other details have been filtered out by this point. You can audit in terms of the business entities that you are setting policy on.
You can play around a bit separating the access decision from the enforcement point. For example, your business logic can have code to determine if a user can access a specific role and present that as a callback to the service layer. Sometimes this will make sense.
Some thoughts to keep in mind:
The more you can push security into a framework, the better. You are asking for a bug (and maybe a vulnerability) if you have dozens of service calls where each one needs to perform security checks in the beginning of the code. If you have a framework, use it.
Some security is best nearest the network. For example, if you wish to ban IP addresses that are spamming you, that definitely shouldn't be in the business layer. The nearer to the network connection you can get the better.
Duplicating security checks is not a problem (unless it's a performance problem). It is often the case that the earlier in the workflow that you can detect a security problem, the better the user experience. That said, you want to protect business operations as close to the implementation as possible to avoid back doors that bypass earlier security checks. This frequently leads to having early checks for the sake of UI but the definitive checks happening late in the business process.
Hope this helps.
VS2013, MVC5, VB
Many posts including here on SO state that claims can increase authorization granularity without incurring a large proliferation of roles. I hope I said that right.
Am I correct in thinking this is only accomplished by using the ClaimValue property?
Even if that's not correct, if the ClaimValue property is used, then some kind of scheme must be employed in assigning the ClaimValue. Are there standard or typical ways to use ClaimValue? Or do we just devise what we need for a given situation?
Addition to post: Regards the comment above about roles: I ask this question because many in the community use claims as roles but it seems that is not the initial/primary purpose for the development of claims in MVC5.
So I should add to my question also asking "Is the use of claims for roles OK?", or should I just be creating a permissions structure, leaving the MVC claims facilities for what seems to be its intended purpose, that of storing identity claims, as opposed to being used with regard to authorization.
An authority will "dictate" what each claim type's standard is (or should be) for the claim value but you don't have to follow them unless you are trying to play nice with something of theirs. Here's an example of one such authority
You can invent your own claim types (and claim value standards) or make up your own standard for one of the existing claim types. They are left ambiguous to be very flexible.
Really, the whole point of making a standard is interoperability. If you don't expect to ever need to do that then it's not a big issue when you don't follow an authority on claims.
You can see a nice list of some commons claims here. Note that one of these you can see is http://schemas.microsoft.com/ws/2008/06/identity/claims/role so trivially you can see that roles are ok.
This is a fundamental design question about the service layer in my application, which forms the core application functionality. Pretty much every remote call reaches a service sooner or later.
Now I am wondering if
every service method should have a User argument, for which the operation should be performed
or if the service should always query the security implementation, which User is currently logged in, and operate on that user
This is basically a flexibility vs security decision, I guess.. What would you do?
There is also a DoS aspect to consider.
One approach is to offer (depending on your context) a publicly available instance / entry point to the services, on a well throttled set-up; and a less restricted instance to an internal trusted environment.
In a similar vein, if you identify where traffic originates you can (or should) be able to provide better QoS to trusted parties.
So, I would possibly keep the core system (the services you write) fairly open / flexible, and handle some of the security related stuff elsewhere (probably in the underlying platform).
Just because you write one set of services doesn't mean you can only expose those in one place and all at the same time (to the same clients).
I think you should decide which methods will need a user argument and which will need a logged in user. You'll get the following method types as a result for this:
1.) Type1: Method is best to have a User argument.
2.) Type2: Method is best to not have a User argument.
3.) Type3: A combination of 1.) and 2.)
The solution of 1.) and 2.) is simple, because they are trivial cases.
The solution of 3.) is to overload the method to have a version of 1.) type and another version of 2.) type.
I try to look at security as an aspect. User argument is required for things other than authentication as well. But, I think control should reach the service layer's more important methods only if the user has been authenticated by some other filter. You can't have every method in the service layer querying the security module before proceeding.
Most of the literature on security talks about the importance of defining a security policy before starting to workout on the mechanisms and implementation. While this seems logical, it is quite unclear as to what defining a security policy really means.
Has anyone here had any experience in defining a security policy, and if so:
1) What is the outcome of such a definition? Is the form of such a policy, for say distributed system, a document containing a series of statements on the security requirements (what is allowed and what is not) of the system?
2) Can the policy take the a machine readable form (if that makes sense) and if so how can it be used?
3) How does one maintain such a policy? Is policy maintained as documentation (as with all the rest of the documentation) on the system?
4) Is is necessary to make references to the policy document in code?
Brian
You should take one of the standard security policies and work from there. The one that is most common is PCI compliance (Payment Card Industry). It's very well thought out and except for a few soft spots, generally good. I've never heard of a machine readable policy except for a Microsoft Active Directory definition or a series of Linux iptables rules.
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
EDIT:
Check out SE Linux policies also:
http://en.wikipedia.org/wiki/Security-Enhanced_Linux
The Open Web Application Security Project OWASP is a language-agnostic project to educate about security and provide tools to test and support software. While it is web-centric, many of the core ideas are widely applicable. The website is geared towards both software engineers as well as management.
When people talk about "security policy", they might be referring to two different types of security policy.
One of them are high level ones, usually defined by managements. This security policy's primary readers are human. It is a document defining the goal, context, expectations, and requirements of security in the management's mind. Languages used inside this policy could be vague, but it's the elementary "law" of security in the applying context. Everyone involved should follow such policy.
1) The outcome of such policy is the clearly defined security requirements from the management. With this polices, everyone involved can understand the management's expectation and make security-related judgment accordingly when necessary.
2) As the primary readers of such security policies are human, and the statements are usually very general, it may not be in machine readable form. However, there may be a couple of documents defined base on the policy, namely security guidelines, procedures, and manuals. They are in the order of increasing level of details on how security should actually be implemented. For example, the requirements defined in the security policy may be realized into hardening manuals for different OS, so that the Administrators and Engineers can perform hardening tasks efficiently without spending too much time interpretation the management's thoughts. The hardening manuals may then be turned into a set of machine readable configurations (e.g. min password length, max failure login count before locking the account, etc) automating the hardening tasks.
3) The document should be made accessible to everyone involved, and regularly reviewed by management.
4) Practically it might be hard to make such references. Security policies might be updated from time to time, and you will probably not want to recompile your program if the policy changes just affect some parameters. However, it's nice to reference the policy in development documents like design sepc.
Another type of "security policies" might just refer to those sets of parameters intake be security programs. I found that some security programs really like to use the word "policy" to make their configurations more organized and structures. But anyway, these "security policies" are really just values and/or instructions for security programs to follow. For example, Windows has its own set of "security policies" for user to configure audit loggings, user rights and etc. This type of "security policies" (parameters for programs) is actually defined based on the 1st type of "security policies" (requirements from management) as mentioned above.
I might be writing too much on this. Hope it helps.
If you have to design a security policy, why not think about users and permissions?
So, let's say you have an API to something. Consider some arrangement of users that divides them in what they want to do and what minimum permissions they need to do it. So if someone only has to read documents from a database, the API itself won't let the user do something else.
Imagine this is a web JSON API. The user clicks a button and JS processes a request, and sends it. Normally it works fine, but if someone tampers the request, the server simply returns some error code because it is whitelisting just a few actions the user can do.
So I think it all boils down to users and permissions.