March 9, 2021
Hot Topics:

Implementing Simple Role-Based Security in Managed C++

  • By Kate Gregory
  • Send Email »
  • More Articles »

Permission Sets

Permission sets can be used imperatively or declaratively, the documentation likes to say, which means you can either call a function or add an attribute. Let's start with the imperative way.

I added a class to my console project. It isn't even a managed class, and it only has a constructor and destructor:

class AccessControlled

(I don't need a destructor, but I right-clicked the project in Class View and chose Add, Add Class and added a generic C++ class, and that gave me a constructor and destructor.) The implementation file looks like this:

#include "StdAfx.h"
#include "accesscontrolled.h"

using namespace System;
using namespace System::Security::Permissions;
using namespace System::Security::Principal;

    //String* role = "BUILTIN\\Administrators";
    String* role = "JSERV\\CodeGuru";
    PrincipalPermission* p = new PrincipalPermission(0,role);


The first line of this constructor is vital: without it the code will compile but will always react as though you are not in the group. The SetPrincipalPolicy instructs the framework to create WindowsPrincipal objects by default.

The code creates a PrincipalPermission object that represents being in a particular role. (The role names used in this example follow the same rules as those used for IsInRole().) The first parameter is 0 here, to indicate that any user identity is acceptable. You can pass in a string representing a specific user if you wish. Having created a PrincipalPermissions object, you now demand that the individual running this application meets the conditions in that object. If the demand fails, a security exception will be thrown.

I added a few more lines to _tmain() to create an AccessControlled object, triggering a call to the constructor:

AccessControlled* ac = new AccessControlled();
Console::WriteLine("created the access controlled object");

When I am in the CodeGuru group, this works. When I am not, it throws a SecurityException.

The other way to use PrincipalPermissions is as an attribute, declaratively. This requires the class to be garbage collected, since only managed classes can have attributes:

using namespace System::Security::Permissions;

                              Role = "BUILTIN\\Administrators")]
__gc class AccessControlled

Now the call to SetPrincipalPolicy must be before the attempt to construct the AccessControlled object:


AccessControlled* ac = new AccessControlled();
Console::WriteLine("created the access controlled object");

The constructor itself no longer needs any security code. No-one can create or use an AccessControlled object unless they are in the specified role.


When you build .NET applications, you get a lot of security code without writing it yourself. It's easy to determine who a user is, and what role (Windows group) the user is in. You can deny access to specific methods or entire classes based on the user's identity. Now there's no excuse for skimping on security. Oh, and one more tip: if you're administrator on your own machine, stop it! Give yourself another account with less power, and find out what life is like for the users of those applications you write. I assure you, it will be an eye-opener.

About the Author

Kate Gregory is a founding partner of Gregory Consulting Limited (www.gregcons.com). In January 2002, she was appointed MSDN Regional Director for Toronto, Canada. Her experience with C++ stretches back to before Visual C++ existed. She is a well-known speaker and lecturer at colleges and Microsoft events on subjects such as .NET, Visual Studio, XML, UML, C++, Java, and the Internet. Kate and her colleagues at Gregory Consulting specialize in combining software develoment with Web site development to create active sites. They build quality custom and off-the-shelf software components for Web pages and other applications. Kate is the author of numerous books for Que, including Special Edition Using Visual C++ .NET.

# # #

Page 2 of 2

This article was originally published on October 18, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date