Enhancement Request

Apr 26, 2010 at 10:02 PM
Edited Apr 26, 2010 at 10:05 PM

I have the following problem that needs a solution: We have a number of site collections where we would like to enforce particular security settings. We'ld like to have a solution that automatically runs every <period of time, probably weekly> to reapply the security settings according to it's security template setup. A typical security setup for a site collection would be:


Visitors (typically, all authenticated users) have read (or in some site collection cases, contribute) rights and all site collection members (typically, one or more AD groups) have design rights to the site collection, with the exception of the subsite node/branch that is called "private" (as in /sites/sitecollectionA/private). Starting at the root of the /private subsite collection, only the sitecollection members have read rights, and only the site collection owners have design rights. Every time the solution runs, it should reapply the rights, as set up in the security template for the given site collection, to that site collection.


Here's a possible kicker though: The security template for a given site collection would be maintained by a sysop not much familiar with Sharepoint nor its intricacies - they would be editing it to enforce a particular security context they were told to implement....would it be possible to create an adjunct program that would read the existing security template, facilitate the changes the sysop needs to make, then output and apply the appropriate security template to the site collection?



Aug 11, 2010 at 9:27 AM

Sorry I haven't replied to this until now.

To have the security template applied every <period of time>, create a timer job that applies the template. Note though that when using timer jobs code might in some cases execute "too fast" wich can cause sharepoint exceptions (like "operation aborted"). Especially if you apply the security template in an async event receiver. A typical scenario for this would be that you use the event receiver to apply the template and use a timer job to create or update items that fires the event. Since async events always gets its own thread, so one thread running the template can cause exceptions for another thread running the same (or other) template. This is not specific thing for this code, but a problem for every type of code running in async event receivers. One solution to at least minimize this problem when using a timer job is to set the jobs thread to run in the lowest priority and also make that thread sleep a little while after an SPItem.Update().

Concerning the "kicker". I actually don't think that a person not familiar with SharePoint and its security model should be messing around with permissions. But yes, it is an interesting idea to write code that makes it simpler to modify the templates without having to login to the server and modify it there. But probably very complicated since the changes must be applied to all web fronts at the same time... Any ideas how to?

Thanks for asking questions!