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.
Related
I have a web-application secured with Keycloak. To keep the description of the service short, we have Users and Documents as entities in the service. The users may have access to none or more documents and may edit or read the document.
Currently we have roles such as Admin, EndUser, Developer etc. We then keep a database table outside of Keycloak that maps the documents to users and what user has what access level to what document. All our end-users have the EndUser role in Keycloak. Every single time an EndUser tries to read/edit a Document, we have to make a lookup in the database table for authorization.
We would like to migrate that table to Keycloak. As I understand it I basically have two options:
Create a lot of roles, two for each document with names such as doc_read_[DOCUMENT-ID] and doc_edit_[DOCUMENT-ID] and so on. Then assign the correct role to the correct user. The downside here is that the number of roles will grow A LOT. Also, the number of roles attached to a user will be very large.
Create a group for each document, with the name of the document id. Have different sub-groups for read/write and then add the users in the correct groups. The downside is that the number of groups will be very large. Also, I will rely Authorization on group names, so the list of group names has to be mapped to the token.
I do not want to add a user-attribute with the document-ids to each user. With this approach I can not get an overview of a document and see what users have access to a given Document.
What is the best practice here? Are there any other solutions to solve this issue? This must be a very common setup.
This is just my opinion.
From what I understand both solutions are suboptimal, adding a role per document is unnatural and too finer grain. And as you already mention this would lead to too many roles that probably you will have to add them into the token.
I would personally use Keycloak just for the authentication part and do the authorization part in the backend. I would also try to group the documents in a way that reflect which user roles are allowed to manipulate them.
Alternatively you might try to use Keycloak's Authorization features to handle that use-case, however I have never used it, so there is not much that I can say about this option.
In my opinion what you want to achieve is something that is very tied to your business logic, I wouldn't recomend depending on keycloak to do it. Your token would constantly grow and management would be a nightmare really.
I see no problem in having a service with good cache to lookup permissions, the bulk of the data won't change much over time.
Our account department has asked me a question, that I didn't know the answer to.
Must first tell, that we are on a hybrid environment.
Each month I export our users from Azure, to forward it to the accounting department. Which then distributes the license costs for the internal department the user works in.
Our problem is that the department field in AD, isn't detailed enough as some of the departments have sub-departments. These sub-departments isn't mentioned in the field, cause we use that for our e-mail signatures, and we do not want to have these in official communication.
The accounting department is asking, if we can enrich the export, with a department number.
So is there a way, where I can use some of the other fields on the users AD object, that gets synchronized to Azure, and again gets into the export from the Active users list?
If your users are synchronized from on-premise AD to Azure AD, you could use the onPremisesExtensionAttributes property of the user object. There are fifteen extensionAttributes in onPremisesExtensionAttributes, you can store the department number in any one of them.
After storing them, you could refer to this link and this post to sync the attributes to Azure AD and get the attributes.
I have created a PowerView using a BISM connection in Enterprise Portal of AX. That PowerView report will be used by 100+ users. I want every user to his/her data in the PowerView instead of viewing the complete data. One option is to create 100+ security roles in SSAS (multidimentional) which is not a viable option. Please guide me how can i achieve dynamic security in PowerView so that every user sees its own view. Thanks.
Power View doesn't not offer any kind of security. You will need to do this in SSAS, but you don't need 100+ security roles. You will want to look into dynamic security. To create dynamic security, you will need some way to relate a user to the information they should see. This usually means adding a field to an existing table or creating new tables.
If all users are secured by the same attributes, they can be contained in a single role. If some users are secured based on one attribute and others based upon another attribute, then you may need multiple roles.
Here's how this might work.
Create a table that contains all users that will need access to your cube.
Create a bridge table that ties the users to the attribute on which you are securing their access. For instance, maybe users can only see certain products so you have a table of User IDs and Product IDs.
Add these tables to your DSV.
Create a user dimension.
Create a measure group based upon your security bridge table
Create a role for this user type and add an MDX statement to the Allowed Member Set. Also, set the Enable visual totals checkbox.
Populate the members for the role, preferably through an AD group rather than individually if you have 100+ users.
Your allowed member set will look something like
Exists(
{[Product].[Product ID].members},
STRTOSET("[Users].[UserName].[UserName].&[" + Username() + "]"),
"Bridge User Product"
)
You can find a good blog post here and a good video about SSAS security here (dynamic security starts around the 35 minute mark).
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.
my company is running peoplesoft 8.49 and i'm looking for a way to determine which users have either had new roles granted to them or had roles removed within the past year.
i can clearly see which users have what roles in the PSROLEUSER table, but there is no modification date on those records. we do not have row-level auditing enabled either.
i'm looking for any suggestions on how to get a complete population of the role grants/revocations for a given period.
No, you can't get that information until and unless you create a process that would maintain such information. Have a look at this link, explains pretty well how Audit process needs to be developed for your requirement.