Programming Security: Secured modules

April 24, 2009 Digital Experience
[This article is part of the documentation preview for the Programming Security section of the Developer manual. You can view the temporary TOC here]

 

We have talked about the building parts: security roots and permissions. Now it is time to explain how to bind the two things together, and, in the process, let Sitefinity know that your module will use security.

First of all, the module should implement SecuredModule, instead of WebModule.Here is how the sample Contacts pluggable module is declared:

public class ContactsModule : SecuredModule 

In a secured module, we have to override two more properties

  • SecurityRoot and
  • SecurityRoots
Lets us first see how they are implemented in the sample Contacts pluggable module:
/// <summary> 
/// Gets the security root. 
/// </summary> 
/// <value>The security root.</value> 
public override Telerik.Security.Permissions.ISecured SecurityRoot 
    get 
    { 
        return this.SecurityRoots[Configuration.ConfigHelper.Handler.DefaultProvider]; 
    } 
 
/// <summary> 
/// Gets the security roots. 
/// </summary> 
/// <value>The security roots.</value> 
public override IDictionary<string, ISecured> SecurityRoots 
    get 
    { 
        return ContactsManager.SecurityRoots; 
    } 
It becomes clear that SecurityRoot returns the security root associated with the current provider, while SecurityRoots returns a dictionary<provider name, security root> of all providers with their associated security roots.

 

The careful reader has already noticed a contradiction: that the provider is not directly connected to a security root. However, if we look at the code for ContactsManager.Security roots:

 

/// <summary> 
/// Gets the security roots. 
/// </summary> 
/// <value>The security roots.</value> 
public static Dictionary<String, ISecured> SecurityRoots 
    get 
    { 
        if (securityRoots == null
        { 
            securityRoots = new Dictionary<String, ISecured>(ContactsManager.Providers.Count); 
            foreach (string name in ContactsManager.Providers.Keys) 
                securityRoots.Add(name, new GlobalPermissions(name)); 
        } 
        return securityRoots; 
    } 

we will see that this is implemented in the manager, and the provider is still not directly connected with a security root. This implementation gives us yet another example that there is an association, but not direct connection.

Here are some more helper (but not required) methods and properties in the ContactsManager that are related to security:

  • public GlobalPermissions Permissions { get; }
    Returns the security root for the current provider
  • public GlobalPermission GetPermission()
    Returns a permission associated with the current security root
  • public GlobalPermission GetPermission(int requestRights)
    Returns a permission associated with the current security root and a request for a set of rights
The next step is to know how to use permissions in your module.

The Progress Team

Read next Progress DataDirect Now Connects to Denodo