Security is very important aspect of any web application. Often developers are more focused on the front end security: public pages vs. pages require authentication, pages those are available for particular roles, section of the page those should be hidden for public users, etc. I'd like to draw your attention to the security of Kentico admin area and available option there.
Personally I love Kentico security model because I haven't met requirements that I couldn't implement with it. I found it very flexible and extremely configurable with multiple levels of granularity. For example you may grant some role with permission to edit content in general, or you may allow to modify particular page type. Moving further you may allow to manage content only within particular folder, meanwhile read only access is granted for other areas. This helps to avoid unauthorized changes to content or data as well as improves editors' user experience: if editor is allowed to manage only one page type he does not need to peek it from the long list of all available page types. This could be achieved with page scopes as well, however it is worth mentioning.
Most of the security configuration could be done in Permissions application. It allows management of access to all available modules throughout the system including custom modules with any permissions implemented there. It is as easy as checking checkbox against particular role from list of available permissions. Sometimes it might not be clear what is the exact permission needed for role in order to perform some action, but playing around for a couple of minutes usually is enough to figure this out. Also it is possible to check what permission is needed with a code, I'll get back to it a bit later.
Another permissions type is permissions for page type. This is where read, create, modify, delete, browse and other permissions for a page type could be configured for some role. This is right place to setup content responsibilities, e.g.: allow news editor to manage news, event editor manage events and so on. To accomplish security setup for pages additional settings in Pages application could be configured.
I'd like to encourage everyone to create many Roles, but with a least permissions. It is much better to have multiple roles assigned to a user vs. a role with multiple permissions. For example there is a user responsible for a data of particular custom table and News section. It is better to create two roles: one to allow management of custom table and another for news management and assign those roles to a user. This is more flexible approach as it allows easily remove some permission from particular user vs. changing role permissions which impacts all user in that role.
Whenever security is being implemented testing is next logical step. This is when Impersonation comes to rescue. It is extremely handy when testing permissions as it allows global admin to login as particular user and see exactly what that user will see and verify that system behaves as expected.
Custom security events
In cases when Kentico security model is not enough to implement some requirement, or you need to override default behavior Kentico suggests implementation of custom security events' handlers. Also AuthorizeResource event handler might be used to check what permission system checks when user accesses some module - just run an app in debug mode in Visual Studio, set breakpoint in handler method, system will hit this method for a couple of times. AuthorizationEventArgs will show the module system checks permissions for and actual permission name.
Kentico provides flexible solution from security stand point. There are many security levels that allows to apply security more or less granular or override them on lower levels.