I am still quite new to MVC, and still trying to wrap my head around the security of MVC.
At the moment, it seems that each 'Action' in controller is restricted by the Roles/Users values listed in the 'Authorize' attribute if present. In a way, this is hardcoded, and will require code change each time the roles link to each controller 'Action' is changed.
I am wondering, is there a way I can use a database to store these values, and retrieve it dynamically instead?
Eg of tables in DB :
- Table to store Action/Role links
- Table to store all Actions
- Table to store all Roles
- Table to store Role/User links
- Table to store all Users
This way, I need not hardcode the required roles for each 'Action' with an 'Authorize' attribute. A change in DB will suffice.
Is the above possible?
Thanks!
Yes, you can do that, but not without writing some custom code.
Take a look at the Thinktecture Resource/Action based authorization. It will allow you to plug in your own AuthorizationManager class.
Related
I'm currently reading a lot about access control possibilites/mechanisms that can be used to protect resources in an application or web application. There's ACL, RBAC, ABAC and many other concepts out there.
Assuming I have developed a simple webservice that returns knowledgebase articles on a route like '/api/article'. The 'controller' connects to the database and fetches all articles and returns them as XML or JSON.
Now I would like to have control over which article in the database is accessible for which user or group. So for instance if user 'peter' accesses the route '/api/article' with his credentials, the webservice shall return only articles that are visible for 'peter'.
I would want to use ACL to control what each user/group can read/write/delete. But what I don't quite understand:
Where does one enforce the access control? Do I just fetch all records in the controller if a user accesses the route '/api/articles' and check each single record against an access control list (that doesn't sound very good performance wise)? Or is there a way that the 'SELECT' statement to the database only return the records that can actually be seen by that specific user?
I really tried hard to find more information on that topic, and there is a lot about different access control mechanisms, but not about where and how the actual enforcement happens...and it even get's more complex if it comes to other actions like modification, deletion and so on...
This is really a matter of implementation and everyone does it its own way. It also depends on the nature of the data, particularly on the size of your authorization (do your have 5 roles and users are attached to them or does each user have a specific set of articles he can access, different for each user - for instance)
If you do not want to make the processing on the controller, you could store the authorization information in your database, in a table which links a user to a set of KB articles, or a role (which would then be reflected in the article). In that case your SELECT query would just pass the authenticated user ID. This requires that the maintenance of the relationship is done of the database, which may not be obvious.
Alternatively you can store the ACL on the controller and build a query from there - for specific articles or groups of articles.
Getting all the articles and checking them on the controller is not a good idea (as you mention), DBs have been designed also to avoid such issues.
I was trying to find it in docs or anywhere on the web but I did not find.
What I am asking about?
I am building website for multiple users. Frontend is not important, back backend API is being build in Loopback.
Every user will be assigned to some, let's name it GROUP.
Group content will be then exposed on subdomain but it is not important now.
Users will be kind of admins of their group.
I will have plenty of different models, but I will always have to protect user from accessing elements which not belongs to his group.
How should I do it? I think it will be some middleware but I do not know how to do it properly.
Of course, every user and every element have field "group_id".
I am also trying to find a good solution... I did find this npm package that looks worth a try: https://www.npmjs.com/package/loopback-component-access-groups
Here is a short description of what the package is used for:
"This loopback component enables you to add multi-tenant style access controls to a loopback application. It enables you to restrict access to model data based on a user's roles within a specific context."
I'm struggeling with the same problem, and I did not yet find a satisfatory response.
My workaround is explained in this question. I've got my user ID and with this, I retrieve the data I need to restrict the access. Then I alter the query in accordance with fetched data.
I'm working on two Domino databases that contain XPages :
the 1st database is a public database,
the 2nd one is restricted to a group (let's say the HR team)
I'm building an XPage in the public DB and I need to populate a sessionScope variable with the data of the HR's database (for example the HR id of the user)
So, as the normal users will not have access to the HR DB, a #Dblookup is not allowed.
Using sessionAsSigner method needs to re-sign all elements of the db each time a developer is modifying a XPages component (otherwise the sessionAsSigner element is unknown).
Then, how to query a database that I do normally not have access ?
Do I have to call an agent with higher access than the connected users ?
And then, how to populate the sessionScope variable ?
Any help will be greatly appreciated
There are a few options, but as Knut says, without a shadow of a doubt, the best practice approach is to use sessionAsSigner.
Source control can be used to allow multiple developers to work on their own instance of the design. Swiper can be used to suppress signatures from the source control repository to minimise conflicts.
All other options I can think of (e.g. periodic exports, using a runOnServer agent) will take longer to code, be more complex and will require you, as the developer, to manage the security implications of exposing the data.
I'm investigating ServiceStack's Authorization feature and want to use Couchbase as my data store. I understand there isn't an IUserAuthRepository implementation for Couchbase so I'd have to develop my own, which isn't a problem.
The issue I am having is if I store the built-in UserAuth object as-is, CB it uses the Id field as the document identifier. This is a problem because I believe the identifier should be object type specific, otherwise a separate 'bucket' would be required to prevent conflicting id's across different objects. I don't really want to have lots of buckets unless I have to.
My preference would be to have the document id set to the type of the object plus the object specific identifier.
eg Using Id "UserAuth_1234" or using UserName "UserAuth_MikeGoldsmith"
Is my assumption of trying to re-use a bucket for different application objects valid or should I be thinking about a bucket per object-type / namespace?
Any direction would be welcome, both from Couchbase and ServiceStack enthusiasts.
Thanks
Additional Info
Ok, so from John's answer I will assume my additional property for the object type is valid.
I found this post where Mythz suggests the BootStrapApi example extends the AuthUser with custom properties. However, to me it looks like the AuthUser is persisted twice, first as the AuthUser and again as the User object (both times using the OrmLiteAuthRepository). Am I right?
Essentially, I want to utilise the SS auth feature, but control the POCO object that will be saved into Couchbase. Can someone give some direction if this is possible and if so, what I need to implement / hook into?
I tried implementing a Couchbase version of IUserAuthRepository, however it uses the UseAuth concrete type so I can't use my own object.
I also tried hooking into the OnAuthenticated method of AuthUserSession but at this point the UserAuth POCO will have been persisted using the register IUserAuthRepository.
I'm happy to use the CredentialsAuthProvider as I just want username/password authentication. More could be added later.
Thanks again!
Buckets are loosely analogous to databases in the relational world, so generally they shouldn't be mapped to application objects. I'm not familiar with ServiceStack's auth feature, but your suggestion to use meaningful, prefixed keys seems reasonable and is a common approach for providing document taxonomy.
Keep in mind that in Couchbase, there's no field in the document that's considered an "id" or "key" field. The key used to store the document is available in metadata, but is not part of the JSON document itself. So if you're able to take advantage of views, then you could also store a document with a type attribute and then query by some non-id property. In other words, the key in the key value doesn't have to be the way you retrieve the user auth document.
Also, there are developers who use key prefixing as a way to provide document taxonomy for views, so you're key pattern above would work for that too. My preference is a type property, but that's no more valid than your suggestion.
I've come across the ServiceStack UseCase examples, with one that addresses my Custom Authentication issue directy.
I was able to override the TryAuthenticate method and use my own UserRepository that backs onto Couchbase.
I'm using my own User class as and entity provider for security system in symfony 2.0.
I noticed that on each reload of the page symfony is fetching user from db:
SELECT t0.id AS id1, t0.username AS username2, t0.salt AS salt3,
t0.password AS password4, t0.email AS email5, t0.is_active AS
is_active6, t0.credentials AS credentials7 FROM w9_users t0 WHERE
t0.id = ? Parameters: ['23'] Time: 4.43 ms
Is there any easy way to disable this behaviour? Maybe serialize user data in session variables or cache them some way?
You can change this behavior in the refreshUser method of your UserProvider.
You should be careful when doing this with doctrine: There is an issue at FosUserBundle github, explaining the pitfalls:
Storing it in the session would lead to several issues, which is why it is not done by default:
if an admin change the permissions of a user, the changes will have an effect only the next time you retrieve the user from the database. So caching the user must be done carefully to avoid security issues
if you simply reuse the user which was serialized in the session, it will not be managed by Doctrine anymore. This means that as soon as you want to modify the user or to use the user in a relation, you will have to merge it back into the UnitOfWork (which will return a different object than the one used by the firewall). Merging will trigger a DB query too. And requiring such logic will break some of the built-in controller which are expecting to be able to use the user object for updates.