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.
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.
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.
I am trying to find out if the currently logged on user has a certain security role. I've looked on Google (couldn't find an answer) and the SDk examples (they seemed way too complicated). So, if you know the name of the security role and the user ID, how do you check to see if the user has that role?
If you browse the folder structure of the CRM 2011 SDK (link: https://www.microsoft.com/en-us/download/details.aspx?id=24004) to this location you will find what you are looking for:
.\SDK\SampleCode\CS\BusinessDataModel\UsersAndRoles\DoesUserBelongToRole.cs
It provides a sample built as a C# Console application. The code will work in ASP.NET as long as the app pool user is authorized to access the CRM Organization that you are trying to connect to.
Hope this helps
You should be able to find lots of examples out there. However to get the current users roles in JavaScript you can use:-
Xrm.Page.context.getUserRoles()
That however will return a list of GUID's which you then need to compare with roles in the system. This part is a bit trickier however here is an article that shows pretty clearly how to do it
http://www.infinite-x.net/2010/11/16/retreiving-user-roles-in-crm-2011/
At a high level you need to do an OData query (against RoleSet) to return the role (or roles) that you are wanting to compare. Then you compare the GUID's of those roles against the GUID's returned by the getUserRoles() function and you're good to go!
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.