Deadbolt's documentation is sparse, really.
Let's say that I have a standard User. The User object I use has a method - "getThing"
I want a role that applies for a "getThing" value of more than 50.
How would I go about doing this? Is this possible, or am I misunderstanding deadbolt?
Roles represent static constraints, e.g. the subject has role x and access to a resource requires the subject to have role y.
For your requirements, you need to use a dynamic constraint. This is some arbitrary rule defined by you that must be satisfied to allow access to a resource.
You can read about the different constraints in the documentation, including dynamic constraints.
Related
Maybe I didn't really get the concept but basicly if you say you're compatible with SCIM then there must be certain expectations of properties that belong to identities am I right?
For an example if you take a look at the example createUser request from
https://developers.onelogin.com/scim/implement-scim-api
you will see a variety of different properties like displayName, nickName etc..
My use case however requires only one name, the userName.
My question is, are any of these even required to say that you are SCIM compliant?
The RFC7643 indicates that the id parameter must be included.
The requirement for the other properties depends on the resource type and thus schemas used by your application. For a user resource, the section 4.1 of the RFC indicates that the userName is also required.
Every user has one or more roles, every role has one or more permissions. So far I can gather all permissions that are associated to a user via the roles.
The Problem
Some permissions have some constraints. For example:
A user can edit all posts that belong to his site, but no other posts.
Therefore the permission "edit post" should have this constraint.
Regarding the model: If the Constraints are related to the permission, I can't resolve which constraints are active for the particular user.
The user model can have an attribute like "site", but not all users, that belong to one site should have the constraint mentioned above. Some of them should be able to edit all posts.
Question
What is the best way to determine which constraint is active for a particular user. Do I have to split this into seperate permissions and integrate the constraints into the permission model or is there a better solution? I stumbled upon attribute based access control but I am not sure if I should switch to a completely different appoach
Any help is appreciated :)
I replied the following to a previous similar question
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.
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
Our current authorization strategy on our site is very tightly coupled to our RDB's schema - which in some ways is a good thing, since it means the permissions available to a user exactly match what he should have, assuming a correct interpretation of the data. So when we query for authorization, we're asking about foreign key/m2m relationships.
I see two main problems with this: first, interpreting relational data is much more difficult to get right than reading explicit permissions from a separate table. The bigger problem I see is that this does not scale. As the app has grown, our permissions checks have gone from a single query across three tables to multiple queries across ten or more tables.
The strategy I've seen in a lot of places that solves this problem is explicit authorization (roles- or claims-based for example). Because this kind of thing is simple enough to just stick in a single table, it seems simpler, faster, and more scalable. The thing that bothers me about it is this: how do you avoid duplication of data?
For example, I have a User that owns a Design. That's currently accomplished with a foreign key. In switching to explicit authorization, I would add the user's id to a table containing the design's id and type. Should I remove the foreign key as well? Should permissions-relevant relationships always be mediated by the permissions table, or should I duplicate the data between the relational representation and the permissions table?
It seems like one the downsides of moving to explicit authorization could include performance, especially if a service call or something was required to fully discover permissions.
I think you're on the right track with roles.
When logging in, you should request your roles as scopes. It's not a terrible idea to namespace them by API and maybe group ids, if they apply.
scopes: ['forum:admin:somegroupid']
The login service could then validate that role by asking the service associated with the namespace.
GET https://forum-api.company.tld/grant_scope/[user_id]?scope=forum:admin:somegroupid
Which then returns whether that user can have that scope and the description of thats scope. Then the login service may include that scope in the generated jwt for that request.
Non subselected scopes should be validated at the route level (say if it were a role that wasn't specific to any group or item).
Otherwise, you'll have to do a query to see if that service says that the userid or one of the included scopes is allowed to do the thing. Redis SETs might be nice for this if you didn't want it to be a foreign table.
I think for object-level permissions, joining to a an access table makes sense, but use it as sparingly as possible. For example, in a forum-setting, object-level permissions should be on the forum, not at the threads or post level (except for owners, that are just included in row with the data). Then you can join from post->thread->forum_access to see whether they can write a new object.
TLDR; Use roles when possible and include as scopes that are validated at a route level. Use group level roles as scopes if necessary. Minimally use object-level permissions only when necessary, only on the objects absolutely necessary.
Edit: This is just one of many possible ways to solve your problem.
I have created a forum, but have now found out that to create more traffic I need to enable anonymous users to add posts.
The idea is that a user who doesn't have an account, can write a post, and fill out the following fields (as you can with stackoverflow):
[UserName][Email][Message]
The datamodel is looking something like this (A bit simplified):
ForumThread/ForumPost: [Id][CreatedDate][Title][Message][UserId]...
User: [Name][Email][CreatedDate][Address][City]...
The question is now, what is the best way to extend the existing datamodel to support anonymous users. Anonymous users don't need all the fields as the regular users e.g. Address etc. The pragmatic way would be to create a UserType describing the different types of users, or I could use some inheritance of a user, but this requires quite a bit of redoing.
Is there a third option I have forgotten?
Add a Role property to the User and have Anonymous and Registered as roles. Leave the properties null that are irrelevant to anonymous users. Although personally, I would just refactor into subtypes.
Create a user in the Users table that is an "anonymous" user, and make anonymous posts under that user's userid.
Does anyone have any tips as we develop an application that will require each user to be assigned a permission level. The permission level will determine what functionality is available to the user.
Any advice?
How would you (do you) employ such functionality in your application?
First you need to figure out what functionality you want to cover by your permission system, and in what detail:
Access to tables (List, CRUD)
Functions/Modules
Access on record level (=ACL)
Positive (grant) or Negative (revoke) semantics
What is the "admin" role allowed to do
If you want to restrict access to tables, you can easily set up an additional table containing all the table names, and grant select-list/select-record/insert/update/delete access to the roles/groups, as sketched by JV.
If you want to grant access to functions or modules, have a table of modules and grant execute to roles/groups.
Both functionality is equivalent to grants in SQL.
Access restriction on record level is much more complicated, as you need to model access rights on the status of a record (e.g. "public", "private", "released" in CMS apps), or have explicit permissions on each record.
If you want to implement a permission scheme equivalent to NTFS, you calculate the permission per record based on the group the user is assigned to, and have user-specific permissions that may override the group permissions, and revokes overriding grants.
My applications typically work on table+function / group level, which may be good enough, depending on your requirements.
This is the partial ER diagram for identity module in Turbogears, Python. It implements what you are looking forward to. Users are associated with groups and groups have associated permissions.
The two ways restricted feature availability can be implemented are:
(I prefer)In your controllers check the group to which the user belongs to and moderate your response to the View according to that. Thus View is just a renderer - no business logic.
The View gets the user details like groups and permissions and it decides what to display and what not to (MVC violated).
Read more about MVC (and Turbogears may be).
alt text http://jaivikram.verma.googlepages.com/temp.jpeg
It depends a lot of the language you use and the architecture of your application (web service ? client software ?).
For a server toy project, I though about assigning a minimum permission level to each command, and check it directly when a command network packet is received, triggering a permission error when the user hasn't a high enough level. I might not be suitable for another architecture.
It may be a bit of a dead end to pursue the concept of 'levels'. It may suit your current application, however a data model that consists of a mapping of roles to privileges is more general and suits most purposes.
Assign roles to users. A user may have more than one role, and their role(s) define the privileges they have. The concept is similar to groups, however 'role' is usually easily mapped directly to business logic (think of roles such as 'administrator', 'user', 'clerk', 'account manager', 'regional manager', etc). Privileges also map fairly directly to functions and data objects. You may also be able to map to implementations that use underlying platform access control (e.g. Java privileges).
In the controller code, you check (via their roles) that the user holds the required privilege to perform a function. It is also good practice to modify your views to hide functions that the user does not have the privileges to perform.
In your design you can visualise / document the access control system as a matrix (roles to privileges).