I am researching security frameworks for an ASP.NET MVC3 application that would have some pretty complex authorization rules in terms who can see data, who can create and edit it. Rules such as
- I can only see clients that are part of my company or branch.
- If I am out 15 or less days from the day the record was created and my role is of super user then only I can edit all but two fields on that record. After 16 days or more I can only edit two fields.
My initial thought was to use the Enterprise Security Block and just add customized authorizers, but after reading more about the native support for membership based security in ASP.NET, I am not so sure if Enterprise Security Block is necessary. I have not use neither of the frameworks in a real-world application so looking for some collective wisdom on the topic.
This is the problem with complex field level security. There is no real framework to help you with it, because everything is so custom. The best you can do is extract this into some kind of lookup table, and assign each field a custom identifier in the table, then have a set of columns that indicate each security level. Then, you build your business logic so that you pass in a field and conditions, and it simply responds back whether or not to allow it.
THen you have to figure out what "allow" means in your interface. Disable it? Hide it? ignore it?
I don't envy you.
You might find this semi-interesting.
http://bartreyserhove.blogspot.com/2008/12/field-level-security-using-aspnet-mvc.html
You can use Azman - Microsoft Authorization Manager and its related APIs.
It provides you with roles, actions, permissions and many more configurable options.
Azman uses AD to store most of this. It also provides options to store using local XML and/or configuration files.
You are crossing into more than just direct security concerns here but actually authorization rules AND edit rules. Your auth rules sound quite custom and I feel that you may need to process these rules in your own custom code and then include these Attributes in your own view models.
Im not aware of any frameworks that will give you this by default as these are very custom editing rules. You could call these claims and when you login go against a claims based framework such as windows identity foundations (WIF) but you will still need custom IF stmts to allow editing in your view based on properties you set in your ViewModel such as CustomerViewModel.AllowAddressEdit. Your view needs to then check this property to display DisplayFor or EditorFor. However you should also check these values on postback to ensure a user hasn't just injected values to hack your app.
You can use asp.net security for basic authentication to the site, and you can use it for basic role membership. But since these are site-wide permissions, you will need your own logic to segment users into organizational permissions.
What I've done in the past is use the asp.net membership logic to handle the basic auth stuff, but then keep another structure in your database that maps the user id's to other parameters - like the mentioned organizational level membership, or especially access rights for data-driven structures.
I'm actually surprised there aren't better solutions already built out there for handling more complext membership/permissions situations that many apps need.
Related
I'm working on my first "real" DDD application.
Currently my client does not have access to my domain layer and requests changes to the domain by issuing commands.
I then have a separate (flattened) read model for displaying information (like simple CQRS).
I'm now working on configuration, or specifically, settings that the user configures. Using a blog application as an example, the settings might be the blog title or logo.
I've developed a generic configuration builder that builds a strongly typed configuration object (e.g. BlogSettings) based on a simple key value pair collection. I'm stuck on whether these configuration objects are part of my domain. I need access to them from the client and server.
I'm considering creating a "Shared" library that contains these configuration objects. Is this the correct approach?
Finally where should the code to save such configuration settings live? An easy solution would be to put this code in my Domain.Persistence project, but then, if they are not part of the domain, should they really be there?
Thanks,
Ben
User configurable settings belong to domain if they are strongly typed and modeled based on ubiquitous language, i.e. 'BlogSettings'. The only difference between settings and other domain objects is that conceptually settings are 'domain singletons'. They don't have a life cycle like other Entities and you can only have one instance.
Generic configuration builder belongs to Persistence just like the code that is responsible for saving and reading settings.
Having found this question, I feel obliged to suggest an answer because I don't like the accepted one.
First off I don't see why this has to be a singleton.
Secondly, there is something about settings that is very important: they are usually hierarchical, and they almost always have to have the concept of defaults. Sometimes those defaults are at the item level. Other times you might prefer to replicate a whole set of defaults. Also, consider the fact that settings can use the concept of inheritance: maybe an agency has a setting, but it permits agents the ability to do their own.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
i intend to make group based permission scheme but i am confused about the following:
i have some questions:
What is the best approach User > Group > Roles > Permissions or
User > Roles > Permissions
How to implement the security (login/remember me) in this case (need a link to good tutorial).
The method level security will use the annotation #PreAutorize hasPermission(#, '') or hasRole or what ?
How will i hide components (administration for non admins) in the UI depending on the permissions (UI is JSF) ?
If i hided components in the view what will be the importance of the method level security then ?
To design a security model is not a simple task itself, and without detailed knowledge of the domain, you're trying to secure it's close to impossible. Having said that any advice you can get here will be as general your question is.
1) In most applications the User -> Roles is enough. In more complex ones the User -> Roles -> Permissions could be used, but it all depends on how you'll define the scope of each. Often fine-grained roles and assigning a couple of them to the user is just what you'll need. I'd say putting another level be adding Groups in the middle is a bit too much. Imagine it as a file system - flat-file systems exist and are way less complicated as it may seem. Take your time while deciding this as this is one of the most important decisions and will have many implications that are not always easy to predict.
2) The authentication and remember-me mechanisms are already implemented in Spring Security - all you need to do is choose the implementation that best suits you and configure it using the security namespace support. Do take a look at Petclinic example app, if you haven't already.
3) If you decide on using permissions, you should always check for permissions. Keep the gain level you chose. Be consistent. Always.
4) Depending on the view technology you use, the JSP taglib may come in handy (as mentioned by Ralph). There is a non-such thing for JSF - but it's relatively simple to write something similar.
5) As Ralph said, if you hide something it doesn't mean it doesn't exist any more - it still can be called by an unprivileged user.
Spring Security 4-SNAPSHOT
Authority Groups
http://docs.spring.io/autorepo/docs/spring-security/4.0.0.CI-SNAPSHOT/reference/htmlsingle/#authority-groups
An alternative approach is to partition the authorities into groups and assign
groups to the user.
5) Even if you hide some funсtion in the GUI, a malignant user could send a faked HTTP request that invokes your function.
4) For JSP there is the spring security tag lib, maybe there is something similar for JSF
3) Depends on your implementation of Role - Permission assignment
2) Authentication and remember me is independent of using groups or not.
1) Depends on your needs. Groups make it more difficult, so I would start with User-Role-Permission and would add groups late when I really need it. -- Spring comes with an out of the box solution to assign Users to Privileges. Adding Roles is easy. But if you start with Groups you have to implement it by your own.
I strongly recommend reading the Spring-Security-Docs.
Either you do it in the by spring security recommended way: "Suggested Steps for Getting Started with Spring Security" or you read the (very good) book "Spring Security 3" (written by some of the authors of the framework).
If you follow the tutorial you will find how to do a simple login and remember me.
To differ roles and authorities you have two choices.
There is an integrated solution in spring 3 (you have to search for your one - I don't use it.)
You can implement your own authorization provider that adds the authorities by the already assigned roles.
Everything in Symfony2 looks pretty good however there is one issue I can't seem to find a solution too. The issue is that Symfony2's security component is limited to 30-32 roles/permissions. One of my projects, a project management/issue tracker system, is going to need more than 32 permissions. There are a number of different components of the system that need to have there own set of permissions. Just because someone has create, read, update, or delete permissions to issues does not mean they have those permissions for projects, milestones, etc... Each component is going to need its own create, read, update, and delete permission not to mention component specific permissions and there is no doubt I will reach the 30-32 roles/permission limit.
I have questioned in IRC and the mailing list with no really direction of where to go. I would prefer to be able to just added this functionality on top of the existing security component (preferably through a bundle). I am not sure how I can achieve more than 30-32 roles/permissions with symfony2's security component.
I would really prefer not to have to development my own security system w/ ACL.
as stated before in the question comments by gilden:
But this is exactly the use case for ACL. You can start using the built-in ACL system today! It's quite easy to modify/extend as well to best suit your needs.
For beginners, I think it's best to read these articles from Symfony2 official book in the following order:
Security - Including info about: Authentication and Authorization, Users & Roles, Access Control in Templates & Controllers
Access Control Lists (ACLs) - Including info about: Bootstrapping & configuration, Creating an ACL, an ACE, Checking Access & Cumulative Permissions
Advanced ACL Concepts - Including info about: Design Concepts, Database Table Structure, Scope, Pre- & Post-Authorization Decisions, Process for Reaching Authorization Decisions
There are also some interesting question here at SO.com about Symfony2 ACLs
Good luck!
I think you kind of misunderstood the acl system you can only create 32 kind of role, but by domain object. This is done using bitmasks operations on integers ( this explaining the '32' limitation as an integer is ... well you know the answer ).
So for example the permission to delete one object would be same - 'MASK_DELETE' - for a project a milestone or a ticket. So if you used the ProblematicAclManagerBundle you would just have to do :
$aclManager->addPermission($ticket, $userEntity, MaskBuilder::MASK_DELETE);
or
$aclManager->addPermission($projet, $userEntity, MaskBuilder::MASK_DELETE);
to give your user permission to delete $project or $ticket for instance. It also creates the acl entry for the domain object and the entry for the user if they are not already there. What I need to know though is if you can create different masks names for a class, or every class of a bundle ?
You will find a deeper explaination on acls here
I know this is an old post, but I just wanted to share this with anyone who has a similar answer.
The key to providing a solution is in this sentence in your question:
There are a number of different components of the system that need to have there own set of permissions.
For each of these components you could create a separate voter.
Create a class that extends AclVoter.
Override the supportsClass() method to make sure the voter will only vote for classes of the component it is meant for.
Create your own PermissionMap containing the set of permissions the component needs.
Pass the PermissionMap to the AclVoter in your services configuration.
Tag the voter as security.voter so the AccessDecisionManager will start using it.
This should get you a long way.
I also recommend going thought the code of the ACL Component, there are a lot of features that unfortunately aren't documented.
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.
Even though there are many good CMS tools out there, I've decided to roll my own tools for my website to get some hands on experience. The only thing that is currently eluding me is how to add authentication to secure the administrative tools.
I'm the only one who will be using the administrative tools, so I don't need something as complex as a full-blown log-in and registration system. However, I also don't want to rely on security-through-obscurity and use random page names and such to hide the tools.
What are my options?
OpenID is probably your best bet.
To utilize it for one person as you suggest, just check the username that is authenticated. Yeah, that would amount to hardcoding, but if we're creating a system with only one valid login name, there's no need for anything more complicated.
But creating the alternative shouldn't be that bad. You could also just create a table of roles, and do a query against that table to see if the currently logged in user is an admin. If you want to be fancier later, you can later add different users and roles.
How the users and roles get into the table is up to you.
1) Simply use "WWW-Authenticate: Basic" see Wikipedia for an idea and the related RFC for details.
2) Enable SSL to ensure your cleartext password is encrypted.
SSL is quite standard on web servers. You can even self-sign your certificate.
This will depend in part on what platform will be used by you and your web host. A given platform will likely offer one set of choices that will be easier to access than others.
For instance, ASP.NET running inside of IIS offers Forms, Basic and Windows (NTLM) authentication, as well as certificate-based authentication with the ability to map client certificates to Windows users.
You could certainly implement another authorization schema in an ASP.NET application, and many do. But there happen to be this set of out of the box authentication schemes that you would not have to implement if this were your platform. I expect this is true of any other platform, including the Linux-based platforms.
Be sure to find out what's available out of the box, and what can easily be added, before writing your own.