Much of the authorization and policy of the website I'm creating is wrapped up in group policy, not single user policy. There are some functions, such as searching for the existence of a user group in a user's profile, which need to be repeated over and over again. Since policies don't extend anything, would it be possible for a developer to create some sort of abstract policy object which included this function?
Policy classes do not need to extend base classes, you are free to extend whatever custom class you want. What matters is that the policy class provides the required policy check methods (which vary depending on the resource).
The only slight exception are policies for requests, they should (but currently do not have to) implement \Authorization\Policy\RequestPolicyInterface, however this doesn't stop you from extending classes or implementing additional interfaces.
Related
We are looking at integrating our apps with Openid connect for our react based apps. We have ui and relevant permissions based on user - menus, navigations etc.
Can anyone point to spec or suggest on how do we handle such permissions in relation to openid connect or oauth. Basically how do we make this permissions available to ui, one approach is dedicated API for ui permissions again authorized by access token.
Another approach is permissions in token itself. Scope is one way of holding info, but it is for delegated access. Hence we are thinking to use multivalued custom attributes for holding roles and permissions in access token. But these permissions can also be huge sometimes and thinking hence if it is good idea to keep permissions in access token.
Any valuable pointers or any design approaches for handling ui permissions list please let know, we highly appreciate it.
The most flexible option is a custom API endpoint. An access token should hold important identity values such as these:
User ID
Roles
Company ID
Tenant ID
Country Code
Subscription level
These are claims, and are populated at runtime for each user, unlike scopes, which are fixed at design time.
Access tokens are designed only to be used by APIs, and clients should never read their payload. A good practice can be to return opaque unreadable access tokens to clients, to enforce this.
The actual permissions for a role can be looked up by the API once, then cached. This is preferable to storing large payloads in access tokens.
Finally, permissions for UIs may originate from two data sources: the identity data and your business data. The API can combine a result from both data sources, and transform the result to what the UI needs. Eg which columns are visible, which are read only and so on.
I am building a jsonapi for my website, and while looking at various frontend components I came across
https://github.com/dixieio/redux-json-api/tree/master/docs
Which seems to resolve the endpoint URL directly from the resource type
It is part of the spec/recommendations to have the endpoint resolved exactl by the resource type ? I remember reading comment explaining there isn't an actual type naming convention.
My API has several endpoints for the registration of different types of user
/registration/admin
/registration/customer
etc.
Those endpoint have different business logic associated, but they all return a user type object.
Is this a bad design to have several endpoints returning the same resource type ?
Should I make changes in my code to introduce additional type like registration/user ?
Or should I submit a patch to the library so it accepts custom endpoint URLs ?
I can't address specifically the framework you're using, but you have complete freedom to choose what your HTTP resources represent. If, for example, customers can be corporate and have associated invoices and sales history, but admins are only ever individuals and cannot transact, you could make a strong case for keeping the resources seperate.
One thing you should try to avoid is allowing limitations of software dictate your URI structure. If I were creating this API, and had decided that customers and admins were different types of object, I would have the registration form resources live at /admins/new and /customers/new which would make POST requests to the collection resources at /admins and /customers. I would not have a /registration* at all.
To address your invividual questions:
I don't understand what you mean by ‘returning a resource type’ — are you talking about the representations returned in the responses, or how the back-end functions are creating and returning instances of a class?
I would not add an additional super-type for all kinds of user. Either have one collection per type, or one type for all.
If after considering all of the above and choosing URIs you want, your software cannot handle the structure you have chosen, there are three options:
i) choose more capable software
ii) create a mapping between the incoming URI and the URI handed to your software. Apache mod_rewrite can do this for you
iii) as you suggest, make the software you are already using more capable
Choose the easiest option.
I'm trying different ways of implement multi tenant AppEngine web RESTful interface.
One of them is to use part of the URL as the tenant name.
The problem is that I'm using Jersey as JAX-RS implementation for RESTful interface and I would like a url such as /tenant1/res1 to first be parsed by something that will take the /tenant1 part, set the namespace to tenant1 and then pass the rest of the URL to Jerseys' servlet for regular handling.
The something maybe either ServletFilter or Servlet or something I can't think of.
How can I implement such thing?
What are the possible problems of such implementation?
Thank you,
Ido.
I do exactly that but using Restlet. The namespace uniquely identifies the customer that a user belongs to.
The first URL fragment contains the namespace. I verify the namespace in a RESTLET authenticator (basically a filter) and when the authenticated user does not belong to the given namespace/customer I refuse to proceed.
I use the primary key of the customer as the namespace. This has the added advantage that a valid namespace/customer can be easily (mem-)cached, and I refuse any calls containing invalid namespaces.
Very happy with this setup and no problems encountered.
This is more of a best practices question. Our org currently has "public read" permissions on our org wide defaults for custom objects. We cannot make this private because of the way its working now for internal employees or rather we are trying to avoid this.
I am also creating a customer portal with custom visual force pages...where I display data using SOQL queries.
Is it a good idea to add a clause on the SOQL query to return only those records where the account id matches the logged in user's acount id?
I did it and it works fine...But are there any pitfalls to this method that I am overlooking?
Thanks,
Calvin
Per the Visualforce Documentation
Because standard controllers execute in user mode, in which the
permissions, field-level security, and sharing rules of the current
user are enforced, extending a standard controller allows you to build
a Visualforce page that respects user permissions. Although the
extension class executes in system mode, the standard controller
executes in user mode. As with custom controllers, you can specify
whether a user can execute methods in a controller extension based on
the user's profile.
I believe the idea being, as long as your classes are public with sharing then permissions should be enforced and records should not be returned that the user cannot see (same with fields on a record).
per the Apex Documentation
Apex generally runs in system context; that is, the current user's
permissions, field-level security, and sharing rules aren’t taken into
account during code execution.
Use the with sharing keywords when declaring a class to enforce the sharing rules that apply to the current user. For example:
public with sharing class sharingClass {
// Code here
}
Use the without sharing keywords when declaring a class to ensure that the sharing rules for the current user are not enforced. For example:
public without sharing class noSharing {
// Code here
}
Otherwise you would have to spend hours ensuring that the right permissions applied at exactly the right time for the right user. It would almost completely defeat the purpose of a visualforce page!
Let's say I have a Project model and a User model in a CakePHP application. Using ACL I can control if users can access to projects and/or to particular actions in a ProjectsController.
But I would like to go further and control whether a user is allowed to view a specific project, e.g. accessing a project with id = 3 using a URL like http://example.com/projects/3.
Is this possible with ACL as well or I have to develop additional checks on top of it?
Thanks!
To restrict access to specific values of a model, you'll need to use something other than ACL.
It'll be best to define a relationship between the users and projects, whether that's inclusive or exclusive.
You're probably needing a ProjectUser model (HABTM in Project and User) and a simple function in that model, maybe userAllowed($projectId, $userId), that checks that the user has been given access to that project.