We are trying to write an authorization program to our company.
We've decided to use claim based authorization .
The normal restrictions are pretty easy (Let particular users use particular services ETC) , but I have some kind of special requirement :
I need to filter records of the result set, based on the claim this user have.
For example , I have a service that return a list of people that invest in our company, with details about them and the amount of money they have. Now, an employee shouldn't be able to see other employee details, unless this employee is a direct manager of the employee presented.
This means -> I need the claim attribute to some how effect the result set, and I couldn't find any information online on how to do this.
What you're looking for is usually called fine-grain security, and HERE is one article on doing it with ASP.Net and claims. Also, a search for "asp.net fine grained permissions" will lead you to lots of resources.
This is a pretty involved topic, but it basically involves elegant and effective ways to add filters (e.g. WHERE clauses on SQL queries) to accomplish your row-level application security.
Related
I am using ABP Commercial to implement a custom CRM system. I am looking for an example, a best practice, a library, or even a framework for scoping data according to user IDs and roles.
Simple scoping like just showing entities created by a certain user is fairly straightforward. But what about showing increasingly more broad data based on a hierarchy of user roles.
For example, I might have a basic user role that can only see data created by the user in that role. Then, I might have a manager role that can see his own data and all the data created by the basic users he manages. Contemplating any decent size organization, you can see how this hierarchy might get quite deep.
So can anyone tell me whether there is a facility or module within ABP Commercial or ABP Framework to facilitate this kind of pattern or if there is third party best practice, library, or framework that might work in conjunction with my code to realize this functionality?
In the past I have written my own implementations but I am looking for a DDD or clean architecture based solution.
EDIT
A more specific example of what I'm trying to do is to create an extension of the user class and role class or to add additional entities managed by a domain service that would allow for:
users to have a collection of roles they manage and a collection of specific users they manage, and…
roles to have a collection of other roles they manage (think composite pattern)
These relationships would be used to filter all kinds of queries within my application.
Here are some use cases:
return a list of contacts associated with the clients of my direct reports
return a flattened list of all users managed by me or my reports
return the total revenue of all sales made by users managed by me or my reports
I would like to know about authorization in jUDDI. I would like to give Publisher capabilities to few of my clients And also I want few of my clients to inquire or access only those services which are related to them. I want to hide the rest of the services which are not related to them. Can we achieve this using jUDDI? and How?
As of right now, no. There is an open ticket for this to provide role, group, list, etc access control on a per record (business/service) basis but it hasn't been implemented.
This problem is also a complex one, since UDDI has both a search and a getDetails set of methods. Get Details in the easy one, but search is very complex. Filtering out records and keeping the paging option still functional would be a challenge
I am building a RESTful API where users may create resources on my server using post requests, and later reference them via get requests, etc. One thing I've had trouble deciding on is what IDs the clients should have. I know that there are many ways to do what I'm trying to accomplish, but I'd like to go with a design which follows industry conventions and best design practices.
Should my API decide on the ID for each newly created resource (it would most likely be the primary key for the resource assigned by the database)? Or should I allow users to assign their own reference numbers to their resources?
If I do assign a reference number to each new resource, how should this be returned to the client? The API has some endpoints which allow for bulk item creation, so I would need to list out all of the newly created resources on every response?
I'm conflicted because allowing the user to specify their own IDs is obviously a can of worms - I'd need to verify each ID hasn't been taken, makes database queries a lot weirder as I'd be joining on reference# and userID rather than foreign key. On the other hand, if I assign IDs to each resource it requires clients to have to build some type of response parser and forces them to follow my imposed conventions.
Why not do both? Let the user create there reference and you create your own uid. If the users have to login then you can use there reference and userid unique key. I would also give the uid created back if not needed the client could ignore it.
It wasn't practical (for me) to develop both of the above methods into my application, so I took a leap of faith and allowed the user to choose their own IDs. I quickly found that this complicated development so much that it would have added weeks to my development time, and resulted in much more complex and slow DB queries. So, early on in the project I went back and made it so that I just assign IDs for all created resources.
Life is simple now.
Other popular APIs that I looked at, such as the Instagram API, also assign IDs to certain created resources, which is especially important if you have millions of users who can interact with each-other's resources.
I'm playing around with a spare time project, mainly to try out new stuff :)
This involves designing a REST API for a system that is multi tenant. Lets say you have an "organization" that is the "top" entity, this might have an API key assigned that is used for authenticating each request. So on each request we have an organization associated.
Now when a user of the API would like to get a list of, lets say projects, only those that belong to that organization should be returned. The actual implementation, the queries to the database, is pretty straight forward. However the approach is interesting I think.
You could implement the filtering each time you query the database, but a better approach would be a general pre-query applied to all "organization" related queries, like all queries for enities that belong to an organization. It's all about avoiding the wrong entities from being returned. You could isolate the database, but if that is not possible how would you approach it?
Right now I use NancyFX and RavenDB so input for that stack would be appreciated, but general ideas and best practices, do's and don't is very welcome.
In this case you could isolate your collections by prefixing them with the organization_id. It will duplicate maybe many collections.
Use case with mongodb: http://support.mongohq.com/use-cases/multi-tenant.html
Should database be verifying if user is authorized to perform certain action?
Two examples:
1)User is enrolled in 30 teams max and it can see scoresheet of these teams only. I'm passing in userid and teamid to the stored procedure and fetching the scoresheet only if user is authorized to view the scoresheet. Is it more appropriate to only pass in only teamid and check beforehand what all teams user is enrolled in? Should I do both?
2)Currently I'm passing in userid of the poster and the commentid of the comment to be deleted and I'm deleting comment only if both criteria is met - userid matches to the poster id and commentid matches to the commentid - just to make sure user is deleting his own comment and not somebody else's. Is it an overkill?
Multiple layers of validation is best practice and it doesn't seem like your methods would cause additional overhead. Just make sure to limit connecting to the database once, I've found that the most costly part of running database queries is the connection and cursors.
http://msdn.microsoft.com/en-us/library/aa174437%28v=sql.80%29.aspx
Security experts will tell you that No amount of security is enough! But at the same time you have to find a balance b/w security and unnecessary layers of protection that are bound to affect your application's performance.
Answering your 2nd question first: It is a good idea to pass both userid as well as commentid, and matching both, so that you accidentally don't delete all comments by a particular user.
Coming to your 1st question now: As I understand it, you want users only part of the team to be able to view the team's scoresheet, right? In order to do so passing only the teamid of all the teams the user is a part of will do. I am not sure what you mean by authorization here!
NOTE:
I have answered your question from a theoretical view with no idea about your Table structure or whats written in your Stored Procedures.
Your frontend is a much more friendlier (libraries, frameworks, best practices) environment to implement whatever access restrictions or authorization that you could possibly have in mind. Adding another layer inside the database just adds a lot of complexity and duplicate implementation of your access restrictions.
I would only consider doing it if clients connect and execute commands directly against the database.
So, rely on the ids provided by the application and spend your energy on sanitizing user input and implementing a sane authentication model. You will need it.