I am writing a data management system with Hyperledger Composer. I know about .acl- and .cto-files, but I have no idea how I would go about adding (and saving) permissions via transactions (=during runtime).
Example use case:
A Patient allows a particular Physician to look at his data. The permission is saved, and the Physician can look at the data of the Patient.
The Patient withdraws his permission. The Physician can no longer look at the data.
One could save a list of all patient permissions for every physician, and make it a Patient-only transaction to add their name to the list, but the Modeling Language does not allow lists, only arrays.
Does someone have an idea? :)
suggest to check out the Composer sample networks for code samples - this PII (Personally Identifiable Information) network has similarities to what you're trying to achieve (controlling access to a patient record by the identifier of (in this case) the Physician) https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/lib/logic.js .
Your ACLs can obviously be written to control access to the Patients record (ie he/she has consented) and only allow a matching Physician identifier to access, based on a condition check in the ACL - an example of use of something similar can be found in this Stack Overflow here -> Hyperledger-Composer: ACL-rules with condition of type (r.someArray.indexOf(p.getIdentifier()) > -1) not working
I would say its better to have an array of authorized Physicians per patient (ie a lot less than the converse where a physician might have a lot of patient IDs to check each time). Your array size is a javascript constraint in theory (heap size etc) but see discussion here -> Maximum size of an Array in Javascript
Related
I always think that an address data is a value object since it is immutable and its equality is defined by the same data in all fields. For example, a billing address in a part of a payment and a shipping address is a part of an order or a fulfillment. When someone changes her/his address, a new address data is needed. But, every single sample code/application, I have run into, has an address data as an entity, which its DB table has its own ID. It would make a sense if a system wants to keep track of all addresses where all business activities/events occur. I, however, don't see such intention in those sample code/application. Do I miss something in the regard?
You can't generalize.
Examples are one thing, real world problems are another. You can't say that for all projects one solution fits it all.
I'll give you an example I had in a project conserning aggregate roots.
Logically and legally a subsidiary is an extension of its company, eg. Walmart has its HQ with tax number and everything and subsidiaries without tax number where the actual stuff is sold. Logically, for applying to a goverment funding or something similar, the HQ sends a request for its subsidiary. Here, Walmart HQ is an aggregate root and its subsidiary is a part of an aggregate in funding procedures.
This is a logical example.
What I had is that a subsidiary can legally apply for state funding without the knowledge of HQ! Therefor, HQ is not an aggregate root anymore, but a subsidiary is. It was extremely illogical, but those were the business requirements.
The point is the same with your value object question. Although you can use Address as an example that it is an entity or a value object, it is the requirements of the business that dictate what an address is, and not what is logical.
Pre-note: there are domains where an address should be an entity, like a mail service; we do not talk about those domains
From my experience, people tend to implement an address as an entity because of the persistence: it is easier to persist an address as a sub-entity to a relational database than to persist a value object because of the entities ID that act as primary keys in the storage table.
However, there are tactics that permit storing a value object as an database entity but still using it just as a value object, as it should be. Vaughn Vernon shows how to do this in his book, Chapter 6, sub-chapter Persisting Value Objects.
I've been trying to develop an internal staff portal for our company. There are departments, job grades, working areas, roles (user, editor, admin, super admin, etc...) and special groups (executives, etc) for user grouping.
User must have one (only one) department.
User must have one (only one) job grades.
User must work in minimum one area.
User must have one (only one) roles.
User may have one or more special groups.
Job grades and roles are hierarchical (an grade or role may be inherited of another one) but other ones not.
Users will see only allowed menus and access permitted routes.
User will also select which users can view it when posting a new content.
e.g:
Combination 1: (IT or Finance department) and (Job Grade is one of 9,10,11) and (Area is one of 1,5,8) and (Exclusive special group is one of 1,5,8) except user id=1
Combination 2: (HR department) and (Job Grade is 11) and user_id=3,4,5
Combinations can be related as AND/OR among themselves like Combination 1 AND combination 2
So, there will be lots of contents and every content will have different group permissions. I try to create a DB schema but it's very hard to get all contents that is visible to logged in user. Serialized data would be good for saving combination sets in db but it looks like impossible with serialized data. Is there an advantage to using MongoDB for this issue? How can i save combinations of group/user permissions in tables also?
I researched lots of ACL and RBAC examples but can't find the optimal solution. Please help.
Btw, i use Laravel Framework.
Thanks.
You need to look into attribute-based access control (ABAC - Wikipedia) and the eXtensible Access Control Markup Language (XACML). NIST, the National Institute of Science & Technology gives a great intro to ABAC here.
XACML will give you the ability to express fine-grained access control policies that use you attributes. In your question you have:
user attributes
department
job grade
working area
role
group
object (resource) attributes
content type
content location
content classification
With XACML you can write rules such as:
A user with grade==1 can do the action==edit on content of type==post
if content.department==user.department.
You can have as many rules as you like including conflicting rules or environment rules (deny access before 9am).
Have a look at the ALFA plugin for Eclipse to write your own policies (Wikipedia | Download).
HTH,
David
a conceptual question:
I have a global system which sales agents use to write orders for clients
Agents can register a client locally (within their own instance of the system)
a client can register himself globally
Agents have access to clients based on client-ID and zipcode
Condition:
I cannot have duplicate clients in the system.
Therefore I need to check during registration, if a client already exists.
I can only make a check on zipcode, because client-ID is an instance-based identifier (a client may have ID-123 in instance A and ID-456 in instance B).
Problem:
Is there a way around showing existing clients with exactly matching zipcode to whoever makes a registration since I don't really want to display something like:
please select one of the following:
Zip 12345 - City: Bigcity - Company Name: some corp.
Zip 12345 - City: Bigcity - Company Name: some other corp.
Zip 12345 - City: Bigcity - Company Name: small ltd.
or create new account
to whoever tries to register.
I cannot modify the global/local structure of the system, but I could add elements or identifiers if this helps.
I hope this is enough info to give some input. Let me know if you need more.
Thanks!
If you don't want to show this dialog for confidentiality reasons, then there is little you can do. The input data just doesn't allow to make any hard decisions programmatically. There could be a typo or something, so I wouldn't trust a program to tinker this together for me. I think the only thing you could do is putting new registrations on a shelf, and only add them to the global database, when they have been confirmed as non-duplicate. You could run a process once per hour that does this.
Find all new registrations within the last hour.
For each registration: find possible duplicate in the existing database.
If duplicate exists: notify manager to handle this manually.
If no duplicate exists: confirm the registration, add it to the database.
You could also write a small tool for the person responsible for handing duplicates, that merges the new registration with an existing client and does whatever is required in that case (e.g. notify the person who did the registration, sending the new client-id, etc).
I've been thinking about this all evening (GMT) but I can't seem to figure out a good solution for this one. Here's the case...
I have to create a signup system which distinguishes 4 kinds of "users":
Individual sign ups (require address info)
Group sign ups (don't require address info)
Group contact (require address info)
Application users (don't require address info)
I really cannot come up with a decent way of modeling this into something that makes sense. I'd greatly appreciate it if you could share your ideas.
Thanks in advance!
Sounds like good case for single table inheritance
Requiring certain data is more a function of your application logic than your database. You can definitely define database columns that don't allow NULL values, but they can be set to "" (empty string) without any errors.
As far as how to structure your database, have two separate tables:
User
UserAddress
When you have a new signup that requires contact info, your application will create records in both tables. When a new signup doesn't require address info, your application will only create a record in the User table.
There are a couple considerations here: first, I like to look at User/Group as a case of a Composite pattern. It clearly meets the requirement: you often have to treat the aggregate and individual versions of the entity interchangeably (as you note). Implementing a composite in a database is not that hard. If you are using an ORM, it is pretty simple (inheritance).
On the other part of the question, you always have the ability to create data structures that are mostly empty. Generally, that's a bad idea. So you can say 'well, in the beginning, we don't have any information about the User so we will just leave all the other fields blank.' A better approach is to try and model the phases as if they were part of an FSM. One of the clearest ways to do this in this particular case is to distinguish between Users, Accounts and some other more domain-specific entity, e.g. Subscriber or Customer. Then, I can come and browse using User, sign up and make an Account, then later when you want address and other personal information, become a subscriber. This would also imply inheritance, and you have the added benefit of being able to have a true representation of the population at any time that doesn't require stupid shenanigans like 'SELECT COUNT(*) WHERE _ not null,' etc.
Here's a suggestion from my end after weighing pro's and con's on this model. As I think the ideal setup is to have all users be a user entity that belong to a group without differentiating groups from individuals (except of course flag a group contact person and creating a link with a groups table) we came up with the alternative to copy the group contact user details to the group members when they group is created.
This way all entities that actually are a person will get their own table.
Could this be a good idea? Awaiting your comments :)
I've decided to go with a construction where group members are separated from the user pool anyway. The group members eventually have no relation with a user since they don't require access to mutating their personal data, that's what a group contact person is for. Eventually I could add a possibility for groups to have multiple contact persons, even distinguishing persons that are or are not allowed to edit any member data.
That's my answer on this one.
I'm working on a web site where each user can have multiple roles/permissions such as basic logging in, ordering products, administrating other users, and so on. On top of this, there are stores, and each store can have multiple users administrating it. Each store also has it's own set of permissions.
I've confused myself and am not sure how best to represent this in a db. Right now I'm thinking:
users
roles
users_roles
stores
stores_users
But, should I also have stores_roles and stores_users_roles tables to keep track of separate permissions for the stores or should I keep the roles limited to a single 'roles' table?
I originally thought of having only a single roles table, but then what about users who have roles in multiple stores? I.e., if a user is given a role of let's say 'store product updating' there would need to be some method of determining which store this is referring to. A stores_users_roles table could fix this by having a store_id field, thus a user could have 'store product updating' and 'store product deletion' for store #42 and only 'store product updating' for store #84.
I hope I'm making sense here.
Edit
Thanks for the info everyone. Apparently I have some thinking to do. This is simply a fun project I'm working on, but RBAC has always been something that I wanted to understand better.
This is probably obvious to you by now, but role based access control is hard. My suggestion is, don't try to write your own unless you want that one part to take up all the time you were hoping to spend on the 'cool stuff'.
There are plenty of flexible, thoroughly-tested authorization libraries out there implementing RBAC (sometimes mislabeled as ACL), and my suggestion would be to find one that suits your needs and use it. Don't reinvent the wheel unless you are a wheel geek.
It seems likely to me that if I have permission to do certain roles in a set of stores, then I would probably have the same permissions in each store. So having a single roles table would probably be sufficient. So "joe" can do "store product updating" and "store product deletion", then have a user_stores table to list which stores he has access to. The assumption is for that entire list, he would have the same permissions in all stores.
If the business rules are such that he could update and delete in one store, but only update, no delete, in another store, well then you'll have to get more complex.
In my experience you'll usually be told that you need a lot of flexibility, then once implemented, no one uses it. And the GUI gets very complex and makes it hard to administer.
If the GUI does get complex, I suggest you look at it from the point of view of the store as well as the point of view of the user. In other words, instead of selecting a user, then selecting what permissions they have, and what stores they can access, it may be simpler to first select a store, then select which users have access to which roles in that store. Depends I guess on how many users and how many stores. In a past project I found it far easier to do it one way than the other.
Your model looks ok to me. The only modification I think you need is as to the granularity of the Role. Right now, your role is just an operation.
But first, you need a store_role table, a joint table resolving the Many-to-many relationship b/w a role and a store. ie, one store can have many roles and one role can be done in many stores.
Eg: StoreA can CREATE, UPDATE, DELETE customer. and DELETE customer can be done in StoreA, StoreB and StoreC.
Next, you can freely associate users to store_role_id in the user_store_roles table.
Now, a user_store_role record will have a user_id and a store_role_id:
A collection of
SELECT * FROM USER_STORE_ROLE WHERE user_id = #userID
returns all permitted operations of the user in all the stores.
For a collection of users's roles in a particular store, do an inner join of the above to user_store table adding a WHERE part of like
where STORE_ROLE.store_id = #storeID
Put a store_id in the user_roles table.
If this is Rails, the user model would have_many :stores, :through => :roles