NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Define the new permission

Permission objects define access to protected resources and what operations are allowed. Refer to the standard permissions (FileIOPermission, SecurityPermission, and so forth) for examples of permission objects.

Granularity of permissions

After defining exactly what resources a permission object is designed to protect, the key design decision is to what degree of granularity the resource needs protection. Taking the FileIOPermission as an example, let’s consider several alternate designs:

and so forth. Clearly there are various tradeoffs among the various choices available: the single bit permission is very simple and fast and easy to understand, however it presents a rather stark all-or-nothing choice for administrators. Deciding on granularity is ultimately a subjective decision and a difficult one, but very important in that it determines the degree of control administrators will have in allowing access to the protected resource.

Additionally, overlapping permissions are to be avoided, meaning that once a permission object is defined it should be used thereafter as the exclusive way to protect the resource. Therefore, if the performance cost is not great, some additional granularity and expressability is often a good choice in the design of new permissions.

Avoid overlapping permissions

When the protected resource already has a permission object associated with it use that, don’t invent a new permission. As described above this will simplify the security model that administrators work with.

The careful reader will note that the example above a new permission to protect personnel records in a file actually violates the rule of avoiding overlapping permissions: the personnel record custom permission and the FileIOPermission for the file containing them both potentially may access the data. Other examples exist within the standard permissions: UnmanagedCode permission allows file and just about every other kind of resource access.

While this kind of overlap there are cases where it is workable. In the personnel record permission case, it is clearly infeasible to apply per-record granularity to the entire file system. Furthermore, it is easy to imagine other differently structured files that would call for a completely different kind of granularity of access protection, making an increasingly complex model applied to all files. Alternatively, in the case of UnmanagedCode permission, strict non-overlapping would imply that this is just about the only permission – administrators would be back to making binary “good/bad” decisions about code. Clearly the finer levels of gradation of trust that code access security enables are worth the overlap and the issues it causes.

Given overlap situations, how can this be made a workable situation – how do we save the administrator from contradictions resulting from competing permissions on the same resource? The key to managing this kind of overlap is when one of the permissions is more fine-grained and typically can be granted with lower trust.

For example, in the personnel record access case, there will be many situations where personnel record access permission is granted but no file access is. That is, where limited personnel record access is granted but no file access per se is – that is, code may go through the personnel system to access certain records, but it may not directly use files. Also note that the opposite makes little sense (no personnel record access, but free use of the file that holds the records), and is hence not an important case since no administrator would likely want to do such a thing. Put another way, in high trust situations where direct file access is given out, in all likelihood the personnel record access will naturally be given as well.