I'm bit vague about how to start using the shiro plugin, after reading few documents. I decided against Nimble, as it comes with few tables and UI plugins.
I setup shiro plugin with wildcard realm, with my own tables. I may use permission based (rather tan role based) access control as it scales well. Now, the steps for it.
assign the permission string to the subject, and save it in the db
check the permission through isPermitted, hasPermission (or relevant tags in GSP).
Now,
1. when to use the accesscontrol through filter?
2. is there a closure injected into the controller where I can define the permission for the actions in it? I read somewhere about accessControl static closure on each controller, but not seems to be documented.
3. How do I create a typical access control scenario like only the creator of (something, a post etc) can delete it? One possibility is creating and persisting a permission string based on userid. to check the permission retrieve the object (post), get the userid and compare with subject.. seems bit complicated.. any easy implementation?
thanks a lot..
Babu.
1 when to use the access control security filter?
A. Use accessControl{true} when you want to limit access to controller actions to authenticated users.
B. Use accessControl() when you want to limit access to controller actions, regardless of parameter content, based on permissions "${controllerName}:${actionName}".
C. When you want to limit actions based on parameter content, e.g. only delete a domain object for which you have the delete permission "${name}:${id}:delete", you need to check isPermitted explicitly in the controller.
3 How do I create a typical access control scenario like only the
creator?
I would add a the necessary permission(s) to the user when the post is created, e.g. "post:${postId}:*" This way the permissions belong to users and/or roles, and not to arbitrary domain objects, as intended in the Shiro way of working. As opposed to file system permissions, which belong to files and directories instead of users.
Related
I continue to get a "HTTP/1.1 403 Forbidden" response from a PUT request to /d2l/api/lp/1.2/courses/7917 . This may be a permission problem with the user/role that I'm using, but I can't figure out what specific permissions may be required. Can anyone point me to a list or matrix of valence routes and required permissions? Or, answer for this specific one?
The same appid/userid/username works for the GETs associated with the same path.
confused...
cwt
The permissions associated with API calls should mirror the permissions you'd have to have if you were to perform the relevant function through the Learning Envrionment's web UI. You can think about this problem in two ways:
Frame the question in terms of a user role: identify the class of users you'd reserve this ability for in your existing configuration, and ensure that a user of that role can make the call through the API as you'd expect.
Frame the question in terms of an abstract single user: start with a role that has no privileges and add permissions until you arrive at only the ones required for the API call. This is not a trivial exercise, and the first way is far more useful in the long run.
In this particular case, because the API requires you provide a complete course offering set of properties when you want to update it, you have to have permission to alter all the properties in the set (under the Manage Courses tool). You also need to be able to see the course info in the first place, so you need to have Course Management Console > See Course Info as well.
You're probably safest to look at the permissions array in the Manage Courses and Course Management Console tools for the user roles that would do this thing in the web UI and make sure that the users employing your app also have a similar permissions array specified in those tools.
I've used FluentSecurity in another MVC application and its great, provides a slick implementation.
I now have a requirement to offer application wide roles, plus also provide additional permission control over individiual entities.
My application manages particular locations and a user may have permissions to perform actions at one or more locations, each location has a unique id. I'll need to check a user has a particular role for the location id (effectively adding another dimension to roles). I've got my schema mapped out, along with my repo/service layers.
I was wondering if someone has tackled this type of problem before and whether its worth me trying to solve with FluentSecurity or if I should validate the user has the role required for the location on each GET/POST request (controller or service layer).
I'm getting to achieve this in FluentSecurity I'll have to roll my own policy and capture the location id from the RequestContext.RouteData.
I haven't done exactly what you need to do, but creating a custom policy in FluentSecurity that handles your scenario should not be hard at all. If you feel it is, please let me know and I will have to fix that.
You can find more information on how to create custom policies here:
https://github.com/kristofferahl/FluentSecurity/wiki/Custom-policies
It sounds to me like you might want to split it into two custom policies. You then apply your custom policies like this:
configuration.For<SomeController>()
.AddPolicy<CustomPolicy1>()
.AddPolicy<CustomPolicy2>();
I'm contemplating a multi tenant application - shared database, shared schema. A tenant identifier (tenant key) associates every row with the right tenant.
What i'm not sure about is how to go about loading the tenant_id into some sort of global scope. How should this happen? I assume that I would parse the domain and then look up the tenant_id based on the domain.
My questions:
Where would the lookup happen in a rails application? In an initializer? Is there a better point to do this?
Once I have determined the tenant_id, what is the best way to persist it - a simple session_id?
I use a before filter for the controllers for this function.
You can also sub-class the controller class to DRY out duplicate code in the controllers.
Be careful to remember that access to a given tenant's information needs to be authenticated on a per-user basis. You need to decide if a given user will have access to more than one tenant. Eg should user "joe" have access to tenants 1 and 2? Or should Joe need a per-tenant login?
The login's authorization should control access to the tenant info. Don't rely on the domain name to grant authorization.
Re: where to persist the tenant_id? Store in the session. If access to the session is expensive (stored in DBMS), then make an in-memory copy as an instance variable during the controller startup. Google for how user_ids are often stored.
You also should determine the user experience for if/when a user wants to access a different tenant.
Added To see which welcome screen to load before the user has logged in, looking at the subdomain name is a good choice. To see which subdomain the incoming request used, parse request.fullpath() Docs. Do this in a controller filter.
Since the authorization comes from the user_id, remember to test the case where joe logs in at tenant1.app.com but only has access to tenant2.app.com
Bonus answer Looking for a templating system that will enable your customers to have full control over their tenancy's user interface? Check out Liquid templates. I was very successful in using them to enable my customers to have full control over their look and feel in a safe way.
Re additional questions in comment
See superuser for configuring the web server. The config is web server-specific.
If you want the welcome screen to not be generic, then you must know from the request url how to customize it. Tenant-specific subdomain is the nicest. If no subdomain, then show the generic welcome--when the person logs in you can determine the tenant and how to customize.
Re helper--if you mean a view helper, then I would not recommend it as the primary place where the tenant is determined. Make the #user and #tenant be light-weight models that you look up once and then retrieve from the session during additional requests for the same session. The models will be used by the controllers and, perhaps, passed to the models. The View layer will also be able to see them and use them as necessary.
If the UI may look/will look completely different for the different tenants, then add a "tenant-display" layer in addition to the view. Eg have the view gather the instance variables, find the right Liquid template, then express the view via the template.
You don't want the view to be computing "if tenant_a then x else y"
I am creating a Grails website where users will have access to the resources they create. Till here everything is clear to me. I define ROLE_USER and lock down my controllers and actions using the Config.groovy file.
The issue I am facing is that I have requirement to support group of users such that some resources created by a user can be edited/updated/deleted by other users of the same group. How do I associate a user with a "group" in spring security, what is the design/library I should use here?
What you will need to do is to have your users' roles (the authorizations) come from the database. Once that is the case, you can then easily adjust the roles a user (or set of users) has and create/remove them on the fly. The docs have some pretty good info on how to get the roles to come from the database, so I won't go any more into that here.
Once the dynamic roles are in place, however, you still need to be able to connect roles to the objects that are created. There are essentially two ways you can go about doing this:
Access Control Lists
Custom logic
Depending on the granularity you need and the flexibility you want, one option may be more appealing than another.
Access Control Lists essentially allow you to have a permission mapping between each user and each entity instance. As you can imagine, it's a fair bit of overhead and can perform poorly if you have a large number of entities and users.
Putting together your own logic, on the other hand, is much more flexible because you can set up your own scheme to connect entity instances or entity classes to users and their roles.
I dont think that spring-security provides such functionality out of the box so you will have to do that manually.
For each domain class that you this kind of functionality, store the user name of current logged in user
def authenticateService
def user = authenticateService.principal()
entity.setUser(user?.getUsername())
Then in the update/delete method of the contoller you should check if the role of the current logged in user matches
the role of the user that created the entity. If you have a match you should proceed with the update/delete otherwise throw an exception
/redirect the user to an error page
As role you can use the spring security roles or you can create a property on the user object you have created
So I read about how implementing your own authorization routines are bad!
http://www.nashcoding.com/2011/02/05/using-the-forms-authentication-membership-provider-on-appharbor/
And I got scared, because I've been implementing my actions as such (example, preventing access to account details if authenticated user is not the logged in user)
public ActionResult DisplayAccount(int someid){
Account a = context.Accounts.Single(a => a.id == someid);
// currentUserId() returns userid from FormsAuthentication
if (!a.owner == currentUserId()){
/* Not Authorised! */
}
}
Which apparently means it will break if ASP decides to cache my action (so the action doesn't even get executed).
So I'm now looking into using AuthorizeAttribute to do what I need to do, which is
prevent access to an action if not authenticated
check if authenticated user has access to the retrieved resource
However whenever I think about it, I can't think about how to implement the 2nd point. Roles don't work because its on a site wide level, but within the application there users have roles as well (e.g. Owner, Moderator, Contributor, User etc.), and they only have these roles within their respective parts of the application (e.g. owner of thread, contributor to wiki, moderator of forum etc.)
I have run into several examples of overriding AuthorizeCore. I can sort of imagine creating multiple AuthorizeAttribute subclasses for each resource I have (luckily not many), But just by looking at it, does that mean I have to query the database everytime I hit that action to ensure that the logged in user should be able to access that data, then query the database in my action to get the model, instead of doing that in my query?
So my questions are
am I getting too worried about caching too much? Will any of the following happen
website caches user A details, which is rendered on user B's screen?
website caches admin version of a page (with edit controls), and normal user sees cached version?
Using AuthorizeAttribute is a given, but how do I achieve what I need to do in point 2 without having to hit the database prior to the Action? Or what is the best way to achieve it in any case.
Or do I only use AuthorizeAttribute to determine if the user is logged in, and do other checking logic in my action?
Anyway, I hope this post isn't treading on any old paths (I couldn't find anything on this that I found definitive)
Edit: I guess, if I don't enable caching this problem wouldn't occur, is this correct?
Edit: for now, I am going to going to use vanilla AuthorizeAttribute, then check resource level access in my actions, then make sure I don't use caching for any authenticated actions. Hopefully will get more answers for this over the week.
I used the following approach in a recent project, by creating a DataRightsAttribute that used an enumeration for each supported model type. It works by first extracting the id from the route data, formcollection or querystring. Then it queried up the model type determined by the enum, and did the appropriate check to see if the current user is authorized to access it.
Usage was like this:
[DataRights(ModelType.Customer)]
This was used alongside AuthorizeAttribute (which we overrided), and never noticed any problems with caching.