CRM 2013 - Prevent Deletion of a record based on a condition - dynamics-crm-2013

I have an entity titled Document Access. Now, this entity Document Access has a N:1 relationship with Incident (One Incident can have many Document Access).
When someone creates a new Document Access record, I have a JS which checks if the person who is creating the record (current logged in user) is the same as the Incident's owner. If not, I disallow the creation (this is set on the Save of the record).
The Document Access record's owner can be anyone (not necessarily the Incident's owner). How can I ensure the prevention of the deletion of these Document Access records unless it is done by the Owner of the Incident?
Can I achieve it via Security Roles? I am not able to come up with a solution that can achieve this via Security Roles so that the Delete button does not even appear when a View or a Form is displayed.
Can I achieve the same via JavaScript hooking into the Delete button as part of
the ribbon? If so, how can I get the Incident id that is being selected for Deletion? Would it also be triggered if we did a bulk delete?
If it is a plugin, should it be on the Pre-Validation stage of the Delete operation?

I'll attempt to answer and qualify each of your own options:
Using Security Roles. No because you want to control the deletion based on the ownership of a related entity which isn't possible.
Using JavaScript. You could hide the buttons with a custom JavaScript ribbon rule that compares the Incident owner to the Document Access record owner. However, this approach won't support all use cases including bulk delete.
Using a Plugin. This is the correct approach and registering on Pre-Validation is fine. It will enforce your business rule regardless of where the delete request originates. This could be from a user via the UI, a bulk delete or platform operation such as an external integration request. Make sure you return a meaningful message in the exception that explains the business rule.

The best approcah is to do this through a plugin on Delete of Document Access records.
In your code you may follow this steps:
Retrieve the Owner of the Incident related with the Document Access:
Guid incidentId --> You get this form the lookup field, you have in Document Access to Incident
Entity incident = service.Retrive("incident", incidentId, new ColumnSet("onwerid"));
Check if the user who triggered the plugin is the Owner of the Incident
// context --> execution plugin context
Guid ownerIncident = ((EntityReference)incident.Attributes["ownerid"]).Id;
if(ownerIncident != context.InitiatingUserId)
{
throw new InvalidPluginExecutionContext("Can't delete Documet Access record");
} // otherwise let the record to be deleted

Related

Authorization permissions and UI element visibility - how to implement it cleanly?

I have developed a pretty standard and common authorization permission system for an internal business web application.
There are some roles with permission sets; system administrator can create new roles and assign permissions to them; every web controller method has an attribute to check for specific permission. So far so good.
But then I have the following conversation with the customer:
Customer: "Please, make it possible to hide specific form fields in specific forms for a specific role".
I: "Ok, so the users of this role shouldn't have permissions to modify these fields, right? I can also add a permission check to the method that saves the data."
Customer: "No, no, it's not a permission issue as such, it's just about convenience - this role doesn't need to work with these fields and we want to make the UI less cluttered. The users of this role shouldn't see these fields in this form only; however, there are other forms where it's totally OK to see these fields. Of course, we might later create new roles that will need to see these fields in this form, but by default the fields should be hidden."
And so the permission system gets cluttered with "pseudo-permissions", such as "See field X in form Y". They exist for UI convenience purposes only and have nothing to do with authorization for performing activities on data.
Is it a good practice to control UI through roles & permissions, even when the specific permission has nothing to do with data processing authorization? Is there a clean solution to avoid cluttering the permission system implementation with such UI-only pseudo-permissions and still provide the customer with granular control to achieve cleaner UI for specific roles?

ABAP: List of reports which a particular user is allowed to execute

I wrote some ABAP code which allows to call a SAP report via RFC and return the result as JSON.
Now it would be very nice, if I could determine which reports a given user is allowed to execute.
Is there a way to get the list of reports which the current user is allowed to execute?
Authorisation in SAP is managed using Authorisation Objects, which contain a list of authorisation fields (tcodes, programs, etc) with the role(s) that are allowed to access them. These Authorisation Objects can be displayed and maintained using transaction code SU21 (Maintain Authorisation Objects).
You can use the User Information System (transaction code SUIM) to see existing roles and the authorisation objects that are associated with them. If you need to maintain roles, you can do so in Role Maintenance (transaction code PFCG).
You can check which role a specific user is assigned to by checking the Roles tab in User Maintenance (transaction code SU01). In this transaction, you can also reassign specific users to a certain role.
I recommend reading through the ‘Authorisation Concept’ help page on the SAP website, which details the approach to protection and security in SAP. I would also recommend this page on Authorisation Checks, which provides some background on how the SAP standard authorisation objects are organised.
You can use transaction SUIM to find out the transactions / reports are allowed to execute for specific user.

where are custom permissions for a SharePoint list saved? (SharePoint 2010)

I am developing a POC (SahrePoint 2010) where I can demonstrate that the users can be granted certain permissions on a list for a Date range (for example contribute access for a selected week). I will be breaking permission inheritance and create unique permissions for a list.
I would like the permissions to be revoked automatically after the expiry date. Also, I would like to do this using the Manage Permissions list (_layouts/user.aspx) so that I don't have to maintain a separate list.
I have a couple of questions regarding this:
1. I assume that the custom permissions for any list must be stored n some list. How can get to know in which list the permissions are getting stored?
2. If at all I get to know in which list the permissions are getting stored, will I be able to add columns to that particular list?
I hope that the question is clear.
Permissions are not stored in any list. Rather, every securable object (including sites, lists, folders, and items) has a Role Assignments property that indicates what groups/users currently have access, and what their permissions are (if not inherited).
See the SPRoleAssignment class documentation for more information.
Note that the User Information list is not a "Manage Permissions" list; it stores profile information about users who access the site, but does not store any permission-related information. Further, it's not a typical list at all, in that it does not show up in the SPWeb.Lists collection for a subsite, and its fields are automatically populated by SharePoint's User Profile Service. While you could potentially add more columns to it, you'd be better off using a separate list to store and track your permission information instead of contaminating the site collection user info list.
To have permission changes take place based on an expiry date, you'll need to implement a time-based solution that runs on a regular basis to see if any changes need to be made, such as a custom timer job, a custom site workflow that runs on a schedule, or a Windows scheduled task.

The Implementation of Users permissions SQL and VB.NET

I am currently working on a project that is designed based on SQL and VB.NET. The idea as the following: there are different permissions for users. The administraotr grants each user specific permissions. The idea is illustrated as the following:
For example, user A can get the following permissions:
He is able to add new tender, modify existing tender, add new customer.
User B has the following permissions:
He is able to view existing tenders, add new employees, ... and so on.
The idea of how to implement it in SQL and VB.NET is:
Creating a new table called Permission with the following fields:
UserID (foreign key for the user ID), for each permission there will be a single field so there will be 12 field.
Now, in VB.NET there will be 12 buttons (i.e. Add new tender, Delete tender, ....). Each button will enabled and disabled based on the value of the field (if the field = 1, the button will be enabled).
Here is an example:
In this case, for this user the buttons with the red lines will be enabled and the rest will be disabled, based on his permissions.
It is obvious that this way is SILLY and is not professional to be implemented.
I need your recommendation of how to enhance it.
Thanks
Ideally you want to use an external authorization framework e.g. Microsoft's claims-based authorization or better yet, XACML - the eXtensible Access Control Markup Language.
When you use externalized authorization, all you need to write in your code (if at all) is:
"Can I enabled button foo?". That's a question you send off to the external authorization engine. If you use an engine that "runs on XACML", then you get policy-based, attribute-based access control where you could easily define that:
users that are assigned to a customer can add tenders for that customer
Check out open source solutions or vendor solutions such as Axiomatics, the vendor I work for. Also check out available resources on XACML e.g. http://en.wikipedia.org/wiki/XACML or XACML videos on YouTube.

Securing an external list by filtering for current user

I have set up an external content type with a column that contains Active Directory accounts to map each record to a user. Now I want users to only see those records in the list where the AD-account entry matches the current user's credentials.
So I tried the following approach, and succeeded in creating a user context filter on the ReadItem/create/update/delete operations. However, on the ReadList operation there is no option for it, the wizard has different filter options.
The result is that the current user can see all items in the external list, but can only open those tagged with his account, so the filter definitely works. However having the filter only on items and not on the whole list is useless (items that cannot be opened will confuse the user, a list view might expose the data anyway etc.).
I tried to filter this list with the Current User webpart, which gives us the desired result, but the list itself is of course still sitting in the background and can be opened via URL.
How can I get the user context filter applied on ReadList? And if that is not possible, where and how do you implement such a filter?
Export the BDC Metadata Model from SharePoint Designer and edit it by hand to include the UserContext filter. Then reimport the model through the BDC Service Application in Central Administration.