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.
Related
How I can implement ABAC in nodejs. I want to give access to user using his location and role.
any one have demo for it?
I am refering npm package PolicyLine: npm i policyline refer link - https://www.npmjs.com/package/policyline
Even though this question is a bit old, I still want to give some answer for other users, which have the same or similar question in mind.
To answer your initial question:
It depends on your requirements and application. If you need to hide or show some fields based on permissions and roles, you should go with ABAC. If you just want to do permissions based on models/entities then a simple ACL would work or even just some predefined roles in a simple domain.
So usually you know what you need. Depending on the application one solution (or library) can be totally fine/overkill and in another it is just enough.
BTW:
I also can recommend https://casl.js.org/ which is actively maintained and also offers ABAC (including time based permission checks).
This question might be naive but I would like to know what are the advantages of using Spring security (or any other security framework) versus custom filters (#WebFilter) to restrict pages in a web-app. In a custom filter I can check the session of an user, see if an user bean has been mapped within the session and then check if the user bean has the appropriate role to gain access to my restricted area. So what do I gain by using Spring security, surely it's more secure, if so then how? I'm asking because I find it harder to use than using custom filters. Thanks in advance.
Security Principle: Don't roll your own security unless you're an expert.
See https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own
The Spring guys aren't sitting around making work up for themselves. They are solving real problems. You could implement all of Spring Security's features with your filters, but then you'd have Spring Security, wouldn't you?
Are you handling CSRF and making it convenient?
Are you handling session fixation?
Do your filters handle path traversal?
Are you handling RunAs functionality?
Read the docs and decide if you should use it or not.
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.
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.
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.