Programming Security: Secured modules

Programming Security: Secured modules

April 24, 2009 0 Comments

The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.

[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.
progress-logo

The Progress Guys

View all posts from The Progress Guys on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Comments
Comments are disabled in preview mode.
Topics
 
 
Latest Stories in
Your Inbox
Subscribe
More From Progress
d12fcc0bdb669b804e7f71198c9619a7
5 Questions Automakers Should Ask to Improve Asset Uptime
Download Whitepaper
 
SF_MQ_WCM
2018 Gartner Magic Quadrant Web Content Management (WCM)
Download Whitepaper
 
What-Serverless-Means-For-Enterprice-Apps-Kinvey
What Serverless Means for Enterprise Apps
Watch Webinar