MarkLogic 9.0.8.2
We have developed API to get & set data in MarkLogic, All data are stored in xml format within MarkLogic
Now we want to expose this API endpoint to external users with below operations
READ
INSERT
UPDATE
NODE-UPDATE
EXECUTE
ADMIN
So we want to create different user credentials based on permission like ReadOnly, ExecuteOnly.
What all Roles & Permissions we need to select to make sure they can perform what they are allowed to?
Note upfront: permissions are about document access, privileges about function access. Execute permission in specific only applies to module access, not document access.
There are many ways to organize your security, but ground basics are usually fairly similar. I'll provide a pattern for you, that I personally consider a good practice, and may prove to be a good general starting point for further expansion.
Start with 4 roles with no properties themselves. Put 'read', 'insert', 'update', and 'node-update' in the names.
Create a fifth role with 'defaults' in the name and give it default permissions for the above four roles, where the capability matches the role name (so 'read' for the read-role, etc).
Then create higher level roles for abstract notions like reader, writer, and maintainer. Reader only inherits the read role, writer inherits reader, insert, update and defaults. Maintainer inherits writer. Deletion is a special kind of update, and not distinguishable. Node-update is a subset of update. I have not come across a use case where I wanted to allow node-update, but not a full update.
Execute permissions makes no sense here, since that only applies to modules, not to documents. Execute privileges are used to allow using particular functionality (like sem:sparql, xdmp:http-get, etc). Apply them as appropriate to reader and writer roles.
Avoid applying more dangerous execute privileges like xdmp:spawn, and xdmp:eval to any of the above roles. If you come across a need for that, then create a role that you use for Amps (you can put 'amps' in the name somewhere), and make sure you use that role only for Amps, and never assign it to roles or users.
Last but not least, you often have multiple distinct datasets in the same database, and you might want to control document access to them independently. Consider looking into Compartment Security instead of creating a distinct set of roles per dataset in such cases.
HTH!
Related
In my application each user can create his own system and add team members to it. Each team member in scope of a system has a certain set of permissions, basing on which system decides if team member can access the functionality.
Some examples are:
Access to analytics board
Access to system configuration utility
Access to team management utility
Access to service handling utility
Each team member can have assigned any combination of these permissions.
I'd like to create an UML use case diagram, but i don't know how to represent use cases which are restricted only to team members that are allowed to use them.
Representing permission is like breaking the generalisation os UML use-case diagrams. You need to write them down in your use case scenario and for UML you can have separate section wise representation.
I don't think that use case diagram is sufficient for your requirements. You are talking about a user who has set of permissions. These permission are variable in time. It doesn’t depend on position (what’s more, we are not talking about being a deputy for a boss who just left for holiday).
In this case I always prepare use case such as Manage Permission and an actor is always a user. Then I make a class diagram where the user/permission model is. Then you have several possibilities how to work with permissions:
In every scenario the first step should be checking the permission to
do this steps.
Every use case has a preconditions related to
permissions.
…
Check the diagram where the simplest example is.
In the model part, I use actors inheritance to model right. For example, the
most simple actor is "user" and it is linked to use case "login" only, it gets the minimum right.
Others actors inherit from it. Like that they all have the right to connect to the system.
The most powerful actor, let say Administrator, inherits from all actors like that it gets all rights.
After you can not translate this in code automatically ... :)
QUESTION: /etc/password has a comment field for the users, which is great because it allows a comma separated list of variables that can be used for other purposes. /etc/group does not, so where can I store a group description and additional information.
BACKGROUND: basically we have a custom file server that can use posix permissions to share out volumes. We also have a custom web based GUI for doing things like deleting volumes, adding users and groups... lots of stuff. This is an appliance (like cisco ACS is an appliance), not a live webpage. I am basically trying make user management for the web based GUI and POSIX one in the same... so I need to store a few additional pieces of information for, say, 'group1 is allowed to delete this volume using the GUI... as log as I have a comma separate list, it should provide what I need (I have this for users, but not groups). I'm going thru these hopes because this is an appliance; as such, everything the appliance actually does for the 'user' is handled via system files, and the GUI just serves up that data and allows the 'admins' to modify it. There is a Database between the GUI and backend, bbut the overall architecture pulls information from the OS and serves it to the DB, which the GUI accesses... 20,000+ lines of code use this philosophy, so I would like to maintain it for user and group management, even for settings that are specific to our GUI.
am looking at role-based authentication for the web app at my work. we use coldfusion, which does not seem to have any good rbac libraries made, so we might have to make one from scratch.
looking at a sample data model, objects are tied to permissions.
http://www.mind-it.info/2010/01/09/nist-rbac-data-model/
it looks like a one to many relationship between objects and permissions, which makes sense.
however, i am wondering if these "objects" should be abstract or concrete?
our system will have a few limited types of objects; for sake of example, let us say "news", "events", and "albums". the permissions and roles will most likely be attributed to these types, since all object instances of any of these types will require the same permissions and accessibility for the different roles.
in the example i looked it, it seemed to me that each instance of an object was attached to permissions. if this were the case, i see a lot of overhead in this type of system...
so, i was wondering whether or not these "objects" are in fact the abstract object types that are associated with a role, or if these "objects" are the actual object instances themselves? (or, if the rbac model allows for either implementation...)
thanks!
You should definitely tie permissions to objects. Yes, there is some overhead while developing it, but it is by far the best case.
Think about it, while you're developing lets say the "Add news item" functionality, you create a permission called something like "addNewsItem". Then you simply tie that permission to the roles that you want to have that ability.
The beauty of this system is that once you code your permissions tied to objects (like the add item), you never have to change it if your users or roles ever change. The "Add news item" will always need the "addNewsItem" permission. That never changes.
If you instead wrap your objects with roles for example, and you decide to add a new role - you're going to be going in and changing code to allow that role any permission. Yuck.
Its actually quite easy to implement. Here's a post I did with some basics on implementation:
ColdFusion: Application Options Based on Role?
I am pretty much confused as to when I should implement an ACL (access control list) system in my application though I can easily manage permissions on groups simply by fetching the session group id and restricting the access using the Auth component.
How is an ACL solution better then the approach I discussed above (restricting the group access based on group id) ?
How does implementing an ACL solution simplify things when it comes to managing access rights in your application ?
Till now I have learned that through ACL, permissions can be granted and revoked at runtime, but this functionality is also achievable without using an ACL.
I am very much confused about this, please help me understand the concept, when to use ACL and the benefits of using ACL in your web application.
I prefer to code with cakePHP v1.3 so it would be great if the explanation is given in context of cakephp but any help (language/technology independent) related to my question is greatly appreciated.
You must use ACLs (or an equivalent user permission mechanism such as literal database User and Permission tables) rather than groups if you need to control access to individual entities which vary dynamically. File systems attach ACL's to individual files since you don't want to create a separate group for each file. Database managers attach ACL's to databases, tables, views, stored procedures and whatnot for the same reason. Web servers deal with web applications in the same manner.
In a business application dealing with business entities, you may want to partition access to entities such as e.g. different sales orders, customers, products or divisions within your company, where not everybody is allowed to create/update or even read the same entities. For instance, when sales staff are in direct competition for bonuses, they don't want everybody else to see all the information on their CRM-stored prospects.
Usually, though, you want to keep your access mechanisms as coarse-grained as is humanly possible: groups are usually good enough. Fine-grained access control mechanisms have a tendency to grow complex, expensive, inaccurate and hard to use correctly. They may even decrease security, since administrative frustration encourages people to find clever workarounds...
I think that ACL technic for securising user access to ressources is usefull only for a typical or medium - sized application . for big applications like CRM or financial data warehouses , ACLs will fail to manage a very complex set of user / ressource couples , when the data increase in size , in type and in volume , the ACLs tables made for that purpose will increase too , which it make for me no sense to overload the database server with ACL Tables. There are many others technics used to install security access and permissions and privileges ... The use of ACL files instead does not sound bad but it is not a good idea as files may corrupt from time to time so data failure is over the risk to not have access to a file containing ACL rules or to access a non existing file or a lost one ... The only way to play with permission is to use the business tables used in the context or in the purpose of your application with relationships between your tables and some logic to add to your Service Side Scripts if you are under MVC Architecture or any else ... So Avoid using ACL for very big sized applications.
Pardon the length here...hopefully I didn't go overboard...
I'm in the process of working on my first production MVC application and I'm trying to stick to DDD principles in the process. I've run into some questions related to how to deal with the security requirements of the application and thought I'd see if the SO community could offer some best-practice suggestions.
Domain Information
To use a simplified explanation, this application will have AffiliateCompanies, Users, and Customers.
AffiliateCompanies are hierarchal, so one affiliate can sign up and be tied to the activities of another affiliate. The root is the main company providing the products/services.
Users all belong to an Affiliate entity.
Customers are organizations to which the products/services are sold. Affiliates are assigned to customers such that it is possible for two hierarchically-unrelated affiliates to split a Customer.
Security Information
Rights to perform certain actions in the application will be determined based on an ACL-type of arrangement. Each User object has a property that is a collection of SystemAccessRules that determine what actions they can perform and what the scope of their permissions are (their own objects, their affiliate's objects, or their entire hierarchy's objects). Users can also belong to roles, which themselves have that same collection of SystemAccessRules.
As a result, if a user logs in and wants to see a list of "their" customers, the list could be comprised of customers they are individually assigned to, customers anyone in their affiliate organization is assigned to, or customers anyone in their organization or any of their child affiliate organizations are assigned to.
Database Considerations
DDD aside, at some point the storage strategy has to come into play. In this simple scenario, the tables align with the objects above (including a roles table), with a few support tables to support the relationships between the objects:
AffiliateCustomers - this table allows for a many-to-many relationship between affiliates and customers by storing the PK of each entity as a pair of FKs that are themselves a composite PK for this table.
ACL - this table stores the security information, specifically the subject of the entry (either a user or a role), the action in question (e.g. "CreateCustomer"), the permission (allow or deny), and a scope (their own stuff, their organization's, or their network's).
The Question...Finally
I'm using a combination of repositories and services. I'm trying to keep business logic in the services and out of the repositories or database, but due to the security design here, a simple request for the list of "their" customers could be immensely burdensome, especially as the data set grows. I was trying to use Linq where possible, but this architecture seems not to be very suited. As I see it, here are my choices:
Accept the requesting user as an argument for service methods (or determine it by context), and have the service method populate a list through multiple queries to Linq repository. This would require pulling the list of customers, then iterating through each customer to issue another query to pull the ACL data, then using that data to filter the first list based on permissions. The hierarchy issue would require some fancy Linq footwork (like this), if it's possible at all.
Even if the hierarchy issue could be made to work, it seems like this solution won't perform very well...
Accept the requesting user as an argument, but pass it and the required permission (e.g. "View Customers") to the repository in order to retrieve appropriate data from the database through a stored procedure that would use several EXISTS clauses in a CTE query that could account for the hierarchical nature of the data and the need to check for role and user security.
This pushes a fair amount of logic to the database, which seems very anti-DDD and generally bad.
I'm leaning more toward the second option, but that may be because in my past projects that's how I've done it. I'm not even sure if my design overall is on the right track (in the past the permission declarations were done using bit flags, so it was even easier to do the DB query using bitwise operator).
Has anyone been in similar situations, and if so can you comment on the performance and maintainability of the solution you pursued? I want to stick to high-minded programming principles, but not at the expense of simplicity and common sense.
Have you considered using the specification pattern to pass your business rules down to your data access layer?
The service constructs a specification tree which it passes to the repository. The repository converts the specification into an Expression<Func<Customer, bool>> which it passes to IQueryable<Customer>.Where(...). When the repository materialises the collection, e.g. by calling ToList(), the business rules are translated into SQL and executed on the database server.
Last time I checked, LINQ to SQL didn't support CTEs, so you may need to use a view to flatten the hierarchy.