I have a query that get accounts for a business unit based on a set criteria. When using one business unit, the query works find and brings back the results. Running the same code, changing only the business unit, running with a different business unit, the result come back empty.
If I run this query in HeidiSQL it works for both business units.
Another feature to this problem is in the bad business unit, a Customer Care Rep can not get the results, yet Customer Care Supervisor can. In the good business unit, both can get the results.
This leads me to think there is a problem with security. However I have compared both business units teams and roles and they match.
Is there something else, that I am overlooking that could stop a team from getting data from the database.
From: https://andrewbschultz.com/2011/08/09/business-units-bus-and-security-roles-in-microsoft-dynamics-crm-2011-solution-exports/
Without BUs, the following security configurations would be possible:
A user could have access to his own CRM records
A user could have access to all CRM records
With BUs, the following additional security
configurations are possible:
A user can have access to all records owned by users in his business
unit
A user can have access to all records owned by users in his own
and any child business units
My understanding is that if the records are owned by a user from BU1, then users in BU2 won't be able to access them until ownership is transfered to a user in BU2.
In order to have users in both BUs access the same records, you have to share all of them with at least one (or maybe all) users in BU2.
Related
after some time, I am still struggling to model my domain properly. Let me briefly introduce simplified background.
It is product monitoring SaaS. User needs to obtain a membership which defines his abilities and limits, let's call him a Member. Member can subscribe to products in order to keep track on product changes, and therefore being notified about it. Member can also create a group to which he can add subscribed products in order to customize notification behavior - "hey, in case of these products, notify me only if price drops more than 20%". Simply as that.
At first, I created three aggregates.
ProductAggregate
MembershipAggregate
GroupAggregate
Even though my use case is fairly simply, I can't figure what is a proper way of modeling that.
Member can subscribe to products. Does "subscribe" method belongs to Membership or Product aggregate? Membership can exist without subscriptions, so is Product.
Member can create group – I would say it belongs to GroupAggregate, but membership limits (i.e. member can create max. 3 groups) needs to be checked. Group has no idea about that, so we need to load membership aggregate to check if it is possible.
As you see above, both cases require knowledge about membership limits, so it would be natural to place it all in membership aggregate. On the other hand, pretty much every action in the system will depend on user membership limits and thus everything would have to go through that aggregate – which is obviously bad.
The only solution I came up with is to build membership with method like "canCreateGroup()" etc. and retrieve that aggregate in command handler (application layer). So CreateGroupCommandHandler would do:
Load membership aggregate, execute canCreateGroup
Load group aggregate, execute CreateGroup
However, this way everything related to membership would be checked in application layer (command handlers) and I believe it is a domain responsibility, so it would be wrong as well.
It appears that there's a requirement that no member ever breach their limits. In that case, every operation that could possibly breach the limits has to run through the membership aggregate. There's no way around that.
You can model the process of creating a group as its own process (with state, which enables resumption) in the domain, as in the saga pattern. For a given member ID and group ID, the create group saga:
attempts to add the group to the member's set of pending groups (the member validates that the group would not breach limits; note that this command has to be idempotent)
if that succeeds, records that the member has approved creation of the group
creates the group
if that succeeds, records that the group has been created
moves the group from the member's set of pending groups to the member's set of active groups
if that succeeds, record that the group creation process has completed
The reservation process means that the failure mode would be a group which never gets created stays in pending and eventually prevents a member from creating more groups. This situation can be detected by subscribing to the events from members (you seem to be event sourcing, judging from the tagging) and canceling (or perhaps resuming, depending on the interval) hung group creation attempts.
I'm creating a micro services for example one for user management i.e (roles, credentials, rights, menus etc) related and one for bank account-details, now i have a scenario to getting user roles detail and rights detail from db, is it a good practice to repeat columns of database user management db i.e.(roles, rights) in bank-account db as per requirement or duplicate data in bank-account db ?
Or no need to duplicate data in bank-account db and send a separate call to get user data first from user management db ?
please suggest a best possibility
Waqas,
You're in microservices environment. There is a well-known Domain Driven Design (DDD) with one of a key pattern of Bounded Contexts. That means you should try to avoid mixing the contexts and duplicate the user information in bank-account db (it might be inevitable some time, but I suppose not in your case).
Therefore, it's fine that you have to call user management service in order to gain the required information about your users.
I agree with #Stepan Tsybulski. Also, I suggest you reduce the need for a bounded context to depend on the other to the minimum possible. So, duplication of data is the best option here. However, you do not have to have roles and rights in the Bank Account context / DB. I'd put in the Bank Account context only what's necessary in that context: User details (such as names, birthdates, etc.) + user id.
You get the roles and rights from the session. You manage roles in the User Management context only. It's good for security and consistency, plus it's the reason for using Contexts.
There are many ways to approach a problem, but that's how I'm doing it.
In the systems, there may be data that is restricted in nature.
Sometimes access to specific entities should be easily restricted or granted based on user or group membership.
What is the best way to implement this in the microservice architecture?
#1
Should access control, managing permissions etc. be the responsibility of the microserive itself? Developers will have to implement access control, store, and update permissions for every service. Seems like not very robust and error-prone approach.
#2
Create dedicated microservice handling permission management? This service will be called by other microserives to check access permissions for each entity and filtering entities before returning results. Centralized permissions storage and management is an advantage but microservice will have to make a call to "Permission Service" for each entity to check access rights what may have a negative influence on performance. And developers still have to integrate access checks into their services what leaves space for an error.
#3
Make access control responsibility of the API Gateway or Service Mesh. It is possible to think of an implementation that will automatically filter responses of all services. But in the case when the microservice returns list of entities permissions should be checked for each entity. Still a potential performance problem.
Example
Consider the following synthetic example.
Healthcare system dealing with test results, X-Ray images etc. Health information is very sensitive and should not be disclosed.
Test results should be available only to:
patient
doctor
laboratory
Attending doctor may send the patient to another specialist. A new doctor should have access to test results too. So access can be granted dynamically.
So each entity (e.g. test results, X-Ray image) has a set of rules what users and groups are allowed to access it.
Imagine there is a microservice called "Test Results Service" dealing with test results. Should it be responsible for access control, manage permissions etc.? Or permissions management should be extracted to separate microservice?
Healthcare system may also handle visits to a doctor. Information about patient's visit to the doctor should be available to:
patient
doctor
clinic receptionist
This is the example of a different entity type that requires entity level access restriction based on user or group membership.
It is easy to imagine even more examples when entity level access control is required.
I came to the following generic solution.
ACL security model is used. Each object in the system has associated set of permissions. Permissions defines who and what actions can perform on the object.
Microservices are responsible for entity-level authorization and filter objects in responses based on permissions of the objects.
Central Access Control Service is responsible for the creation, update, and deletion of permissions for all objects in the system. Access Control Service database is the primary store of objects' permissions.
Permissions stored in microservices databases are synchronized with Access Control Service database using event-carried state transfer. Every time, permissions are changed an event is sent to the message broker. Microservices can subscribe to these events to synchronize permissions.
API Gateway can be used as the additional protection layer. API Gateway can call Access Control Service directly (RPC) to check response objects' permissions or load recently revoked permissions.
Design features:
A way to uniquely identify each object in the system is required (e.g. UUID).
Permissions synchronization in microservices are eventual consistent. In case of partitioning between message broker and microservice permissions will not be synchronized. It may be a problem with revocation of the permissions. The solution to this problem is a separate topic.
Looks like security is a part of business logic here. In both examples.
Then security could be a part of data scheme.
For example,
Patient can see his tests:
select * from test_result where patient_id=*patient_id*
Doctor can see all test from his medical department:
select * from test_result where branch_id=*doctor_branch*
I believe that to have separate MS for access control is a really bad idea and could lead serious performance problems. Just imagine situation that somebody with zero entity access tries to fetch all entities each time :) You will always need to handle larger result sets than actually needed.
Firstly, this is very bad idea to have a separate (per microservice) security model. It should be single always cross-cutting all application, because it can lead to a hell with access management, permissions granting and mapping between entities in different microservices.
In second, I assume that you are wrong with understanding how to organize microservices..? You should dedicate the principle of splitting functionality into microservices: by features, by domain, etc. Look at Single Responsibility, DDD and other approaches which helps you to achieve clear behavior of your MS.
So, in best case, you should have to:
Choose right security model ABAC or RBAC - there are a lot of other options, but looking at your example I guess the ABAC is the best one
Create separate MS for access management - the main responsibility of this MS is a CRUD and assignment of groups/roles/permissions/attributes to the people accounts.
Create separate MS for providing only permitted health information.
In third, how it works?:
With ABAC you can setup hierarchical roles/permissions (based on groups/attributes) - it helps you to resolve a delegation path of who is permitted to the data
Setup authorization (via auth-MS) and store the list of permissions (in session, cookies, etc)
Check access for a given user for a needed data in health-info-MS. Here we have several options how to do this:
If you use memory-grids (hazelcast, coherence), you can easily create filters with predicates based on security attributes.
If you're using SQL (hibernate, plain SQL, etc.) you should generate queries to return only permitted data - add security specific criteria to the where clause
Few more details about SQL queries with security check in where: before the SQL execution (if hibernate & spring is easy to do with spring-method-auth hook) you should resolve all permissions assigned to a user - you can do this with call to auth-MS.
Example
We created CRUD permissions for TestResult entity - VIEW, EDIT, DELETE.
The role DOCTOR can see any TestResults - so, it has VIEW permission
The role PATIENT can see only his/her TestResults
So, you create a business rules which provide the correct where clause for each business role (DOCTOR, PATIENT, LAB, etc.) and at the end the SQL request would be like:
For patient who has assigned VIEW permission:
select * from test_result where id=*patient_id* and 1=1
For patient who hasn't assigned VIEW permission:
select * from test_result where id=*patient_id* and 1!=1
NOTE: In business rules we can add 1=1 or 1!=1 to permit/restrict query result
We have to authorize hundreds of users for a cube, and the users must be restricted to individual dimension members. Two dimensions are relevant for the permissioning, a datatype permission (with only 10 members) and a customer dimension (with 2000+ members).
Since one user can be permissioned for any number of datatypes and customers, we could build one role per datatype and one role per customer... ending up with 2010+ roles. The datatype roles are not authorized for any customers and vice versa, therefore we could enable users for any combination of datatypes and customers.
On the other hand, if we create one role per user, we end up with only hundreds of roles. I therefore do not see the benefit of roles in our scenario. We will probably use AMO to maintain the roles.
My question is, if there is a penalty when using one role per user or it this is a tested method. Of course I am also interested in any alternative approach.
Problem in this case is that you don't have any data that would help you automate the roles.
So in order to make use of suggestions by mmarie you will need to further develop your cube and to maintain the user-customer relationship somehow (more horrible admin work).
Technically your scenario seems simple enough to be handled by http://easyroles.com which was made specifically to help out in these situations.
Disclaimer: I am involved with eR tool, but there is no other way I can answer this question since there are no other tools that are made for this.
We have a Salesforce app where we have some custom objects and want to expose the various custom object rcords to customers.
We need to ensure that customers can see only the records belonging to their Account. Because of the way these records are setup(owned by various system users at different levels of processing), we cannot use owner based sharing...and cannot use criteria based sharing since its not dynamic(I cant use criteria based sharing to say "Share this record with all customer portal users who belong to the same Account as the record" at runtime).
So I know I have to use Apex based sharing. I have read up on the sharing objects and the sharing table. But how would I approach this.
I can write a trigger which upon inserting will create a share object and get all userids who belong to the customer portal group and whose account equals the account of the record and associate them with the share object of the record.
But I feel this is overkill correct? Lets say there are 5 users from one of our customers and lets say there are 500 records created a day...that means 2500 share objects a day just for 1 customer...for 10 customers this can go upto 25000...and scale in this way...
Am I right here?
Another problem would be if a new person joined that customer team..unless another process updates the sharing on older records, he/she cannot see the older records.
So is there a better/elegant way to do this? I thought of adding a share object to the group...but there is just one group "Customer portal group" and how do I associate the group with the account of the users?
I will appreciate any thoughts about this.
You should take a look at high-volume customer portal users. They're much cheaper relative to standard customer portal users and should meet your needs. Unlike regular users they have a totally different sharing concept. In a nutshell if they own an object they can see, if not they can't. You can then extend this based on whether a contact or account lookup on the object matches the logged in user.
Read up on this documentation:
License Types (scan to High Volume Customer Portal)
Granting High-Volume Portal Users Access to Records (login required)
You can use groups for sharing to avoid creating so many sharing records. You would have one group per account and one sharing record per account. Instead of managing thousands of sharing records you would have to manage hundreds of groups.
I haven't tried this approach with this many groups, but I read some time ago that it should work (someone posted using a LOT of groups for sharing). If you do try this, please tell us if it worked OK.