I am working on XACML 3.0.Can anyone suggest how to handle descendant resources in XACML3.0 Hierarchical resource scenario?
In Hierarchical resource profile, Scope value can be either 'Children' or 'Descendants'. Descendants means all the resources under the root resource. Children means level 1 Descendants. However this could be related with your resource finder implementation. In WSO2IS, you need to write an extension point to retrieve the children or descendant resources for give root resource. Root resource and the scope value must be sent in the XACML request. You can find more information about the hierarchical resource profile and on writing a resource finder for WSO2IS from this blog post. I guess this would help you.
Related
I'm trying to implement the RBAC (Role-Based Access Control) on a website.
The problem is the permission of nested objects.
Suppose we have some projects on the website. Each user can have a role in each project. e.g. user1 has the admin role in project1 and the customer role in project2.
Admin role, for example, consists of some permissions like Adding subproject, Deleting subproject, etc.
All docs I've read about RBAC, define general permissions like Add subproject, but when a user has this permission, it can add subproject for all projects not a specific project (here project1).
How can I restrict such permission to a specific project?
One bad solution is to define new permissions for each project. So the permissions will be Add subproject to project1, Delete subproject from project1, etc. and defining the corresponding roles like project1 Admin.
But I don't feel good about this redundancy; while the projects themselves can be added/removed, dynamically.
I think you've run into one of the known limitations of RBAC: permissions can only be assigned to user roles (not to resources or operations).
Recently, there has been growing development in permissions services based on Google's Zanzibar paper which describes a more general permissions system that supports describing resources, users, and relationships between them.
In a Zanzibar based system, you would define a resource for Projects, an admin and customer relation for Projects, and then defines tuples to manifest actual relationships representing your data. Thus, you can define <project1, admin, user1> and <project2, customer, user1>, a straightforward way to represent and check granular permissions on resources. This is a conceptual overview but there are concrete services where you can read their implementation specific details as well as try them out.
I stumbled across your post while researching authorization as part of my new job so I'm adding this answer in case others encounter similar challenges. Some resources we've put together than may be useful:
What is Zanzibar?: blog post that gives an overview
Playground: an interactive tool for writing and testing namespaces (there's a pre-written RBAC example you can test as well)
Disclaimer: I am a RBAC beginner
The way i understood RBAC is that you have Permissions which combine actual Resources and Operations.
In your case: The Resource would be "project1" and the Operation would be "create_subproject", so the Permission would be called "project1.create_subproject", which indicates that you have one permission per Resource, hence the mentioned redundancy.
My proposal to your question is to introduce a ResourceGroup. This is not part of the NIST RBAC Standard though. A ResourceGroup would combine Resources of a common type.
The access check goes through all objects in the ResourceGroup and if it finds your specific Resource it can evaluate the allowed Operations
OK. I've got a solution workaround for such a situation.
My problem with granularity was raised because of an extra-large context: where projects themselves are considered to be resources having independent permissions. But the problem is that with such permissions, other nested permissions are not independent anymore. (i.e. create_subproject permission is depended on project_access permission; which breaks granularity.
So the workaround is to define permissions at the project level (assuming the project itself is accessible), and define the tuples of <user, role, project> to specify which user has which roles on each project.
Is there any way to specify custom paths for resources?
Example: <Resource name="User" path="/manageUsers" {...}>
If it's not possible "per resource", can we for example have all the CRUD pages be under a same basepath like: /crud/{/$resource.name} but keep the custom routes without that basepath.
Thank you very much.
EDIT #1
For context, we are building an admin panel that will have a lot of flows, basically step-by-step creation of resources. So I applaud the react-admin library for what it does (manage the CRUD part), but I want more flexibility in how the URLs are going to be.
I will need to have a section called /manageUsers/ that will have some data like a dashboard, and then the list could be /manageUsers/list/.
And then I may need another section called /customers/ that would list directly on that page.
EDIT #2
To give another use case, I'm trying to use graphQL as the dataProvider, and I had to rename all my resources since the rest API is using users where as the graphQL resource is User. So all my urls are now different!
I hope that makes it a bit more clear.
Is there any way to specify custom paths for resources?
No, this is not supported at the moment. One way to tackle this would be to use manageUsers as the resource name and translate it to User in your dataProvider.
I will need to have a section called /manageUsers/ that will have some data like a dashboard, and then the list could be /manageUsers/list/.
Definitely not supported by default either. However, you can replace the default Resource component with your own. It actually just creates routes for the resource inside a React Router switch. Note that you'll probably have to override the redirect prop of some components (such as Edit) because, when passed list, they expect the list to be at the resource root path.
I had to rename all my resources since the rest API is using users where as the graphQL resource is User
That's the dataProvider job to translate resources names into what your backend expect. Use resource names that make sense for your users (url wise).
I am trying to figure out the "right" implementation for an url structure for an application with multitenancy support and shared resources.
Resources: Users, Projects
The URL schema is
host/api/tenant_id/resource[/id][/subresource][/id]
User A (width id = 1) gets a collection of his projects at
GET http://example.com/api/1/projects/
User A creates a new project, readable by
GET http://example.com/api/1/projects/2
Now User A gives another User B (id = 2) access to project 2.
User B would like to see a collection of all projects related to his account via:
GET http://example.com/api/2/projects/
Should the shared project (id = 2) be in this collection besides those, User B created by himself? Or is there a better naming structure for shared resources?
Focusing on the design of URL structures is actually a no-go for RESTful architectures. Roy Fielding:
A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server).
See also this answer.
For your specific problem I would return a list of (basically arbitrary) hypertext links to the projects the user has access to. The links would contain attributes making it clear, whether the project is »owned« or »accessible« by the user. To improve readability you could design your resource URLs as
http://example.com/user/{user id}
http://example.com/project/{project id}
The representation of user after a GET http://example.com/user/2 would contain the list of links like
<a href="http://example.com/project/1" class="owned"/>
<a href="http://example.com/project/2" class="access-permitted"/>
The HATEOAS principle is inherent to REST and makes most »how do I design my URIs« questions obsolete:
The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia.
Maybe one advantage can be in using tenant info in the path. In such way we can easily have for example the lists of objects.
Querying the uri on get /tenant-id/projects
We can have a list of of projects for each entry tenant.
How can be get without tenant info into url?
My 2 cents
I have read a few articles about HATEOAS and the way that API should be implemented such that you can traverse to different states by following the links. But I'm confused as to how the client should be implemented?
From this answer:
The client knows nothing about how the server designs its URIs other
than what it can find out at runtime.
Does the client need to crawl from the root node down to a nested resource to just make a POST if it doesn't know the direct URI?
What would be the purpose of API documentation then?
For implementing HATEOAS server needs to include links to responses that goes from server to client, and client uses these links in response to communicate to server.
For eg. Client request Product list, server will respond with list of products with link to Add, edit and delete the products (if user is able to do that), which will then be transformed in client into links or buttons like Edit Product, Delete Product.
This blog might help you get more understanding.
Does the client need to crawl from the root node down to a nested resource to just make a POST if it doesn't know the direct URI?
Yes unless the root page does not contain the link which describes the POST.
What would be the purpose of API documentation then?
It describes the metadata the client can recognize for example by a link or by a property. So it describes the capabilities of the service.
To answer your first question "Does the client need to crawl from the root node down to a nested resource to just make a POST if it doesn't know the direct URI?"
The answer is No. The client always does not have to crawl from the root node. It is possible to design the URI;s such a way that the navigation to reach the direct URI can be from other views. For example if the purpose of the URI (/Products/product1/Delete) is to delete product , then it should be possible to reach this by either crawling from the /Products or by giving a namespace query of Products/Deleteview. This "DeleteView" URI should give all the URI's of the delete view. i.e it can return a uri collection like Products/product1/Delete, Products/product2/Delete etc.
To your second Question "What would be the purpose of API documentation then?"
Concept of API is a legacy of the past. Ideally the URI itself should be the documentation. This way the client can be programmed to discover and take only things that it can respond to.
We got hold of unique technology which manages these namespaces. so we are shielded from this view manipulation ourselves. I recommend using a technology to manipulate and create these URI namespaces.
I came across many different models for the Access Control in a system. When implementing an Access Control model in any system, we usually hard code the rules/rights in the database(considering an RDBMS) by creating separate tables for the Access Control. Also, these rules/rights can be stored in an XML database.
I would like to know what is the difference between storing the rules on RDBMS and on an XML database? Also, when should we use XACML for implementing an Access Control model in a system? I mean, how one can decide whether one should hardcode the rules/rights in the database or one should use XACML policy language?
Thanks.
Disclaimer: I work for Axiomatics, a vendor implementation of XACML
Storing authorization logic if you go your own way could be done either in the RDBMS or in an XML database. It doesn't matter. I doubt that XML brings you any added capabilities.
Now, if you want an authorization system that can cater for RDBMS systems and other types of applications too (CRM, .NET, Java...) then you want to use a solution that is agnostic of the type of application it protects. That's the goal of XACML, the eXtensible Access Control Markup Language.
XACML provides attribute-based, policy-based access control (ABAC and PBAC). This gives you the ability to write extremely expressive authorization policies and managed them centrally in a single repository. A central authorization engine (called Policy Decision Point or PDP) will then serve decisions to your different applications.
As Bell points out, the minimum set of attributes you will need is typically attributes about the user (Subject), the resource, and the action. XACML also lets you add environment attributes. This means you can write the following type of policy:
Doctors can view the medical records of patients they are assigned to.
Doctors describes the user / subject
view describes the action
medical records describes the targeted resource
of patients describes the targeted resource too. It's metadata about the resource
they are assigned to is an interesting case. It's an attribute that defines the relationship between the doctor and the patient. In ABAC, this gets implemented as doctor.id==patient.assignedDoctorId. This is one of the key benefits of using XACML.
Benefits of XACML include:
- the ability to externalize the authorization logic as mentioned by Bell
- the ability to update authorization logic without going through a development/deployment lifecycle
- the ability to have fine-grained authorization implemented the same way for many different applications
- the ability to have visibility and audits on the authorization logic
HTH
The two are not mutually exclusive.
An XACML policy describes how to translate a set of attributes about an attempted action into a permitted/denied decision. At minimum the attributes would be who the user is (Subject), what they are trying to do (Action) and what they are trying to do it to (Object). Information such as time, the source of the request and many others can be added.
The attributes of the user and the object will still have to be stored in the database. If you are grouping users or objects to simplify administration or to simplify defining access control rules then you're going to have to manage all of that in the database to. All that data will then need to be passed to the XACML Policy Decision Point to return the permit/deny decision.
The advantage of using XACML to define these rules, rather than writing your own decision logic for the rules defined in the database, is that the assessment of the rules can be handed off to an external application. Using a mature, tested XACML implementation (there are open source options) will avoid you making any mistakes in building the checks into your own code.
Hardcoding the policies in your code is a very bad practice I think. In that case you mix the business logic of your resources and the permission check of the access control system. XACML is a big step in the right direction because you can create a fully automatic access control system if you store your rules in a separated place (not hardcoded in the business logic).
Btw you can store that rules in the database too. For example (fictive programming language):
hardcoded RBAC:
#xml
role 1 editor
#/articles
ArticleController
#GET /
readAll () {
if (session.notLoggedIn())
throw 403;
if (session.hasRole("editor"))
return articleModel.readAll();
else
return articleModel.readAllByUserId(session.getUserId());
}
not hardcoded ABAC:
#db
role 1 editor
policy 1 read every article
constraints
endpoint GET /articles
permissions
resource
projections full, owner
role 2 regular user
policy 2 read own articles
constraints
endpoint GET /articles
logged in
permissions
resource
projections owner
#/articles
ArticleController
#GET /
readAll () {
if (session.hasProjection(full))
return articleModel.readAll();
else if (session.hasProjection(owner))
return articleModel.readAllByUserId(session.getUserId());
}
As you see the non hardcoded code is much more clear than the hardcoded because of the code separation.
The XACML is a standard (which knows 10 times more than the example above) so you don't have to learn a new access control system by every project, and you don't have to implement XACML in every language, because others have already done it if you are lucky...