Protecting Resources with Permission Objects

Clarify, Don’t Conflict

Don Kiely

October 30, 2009

4 Min Read
ITPro Today logo in a gray background | ITPro Today

SecureASP.NET

LANGUAGES: ALL

ASP.NET VERSIONS: 1.1

 

Protecting Resources with Permission Objects

Clarify, Don t Conflict

 

By Don Kiely

 

One of the things that wasn tinitially clear to me about CAS permissions is that they are used in two basicways: 1) to protect resources, and 2) to determine whether calling code has thepermission it needs to access the protected resource. Without keeping thatdistinction crystal clear, permissions can be a sticky morass of seeminglyconflicting details. Fortunately, most of the code that goes into custom .NETapplications is not protecting a resource directly, so you can focus yourefforts on one use of permissions.

 

In this installation of columns about .NET permissions, I lllook at using permission classes to protect resources. Next time I ll look atthe other side namely, how to make the calling code handle permissionrequirements gracefully.

 

System.Security.CodeAccessPermission is the mother of mostpermission objects in .NET, so we ll start there to develop an understanding ofhow permissions can protect a resource. It has three broad groups of methodsyou can use:

  • Resource protection, such as Assert, Demand, andDeny. These methods specify how far up the call stack the code has thespecified permission. More about these later in this column.

  • Permission set manipulation, such as Intersect,IsSubsetOf, and Union. These methods let you hook intosecurity policy that defines multiple permissions to extract another permissionset. I ll delve into these in a future column.

  • Other generic object methods, such as Copy andToString. These are the methods that are incidental to the CodeAccessPermissionclass as a .NET object. I ll not explore these any further since they are notdirectly related to code access security.

 

Keep in mind, of course, that permission objects thatderive from CodeAccessPermission can and do add to this basic interface.

 

The most important part of the CodeAccessPermissioninterface, as well as for other permission objects, is that they implement the IPermissioninterface. IPermission requires implementations of the Copy, Demand, Intersect,IsSubsetOf, and Union methods, then build on thatminimal interface.

 

Let s say that you re writing a Web application that makesuse of your company s highly sensitive and secret algorithms for finding outwho is a person s secret Santa. This is highly privileged information obviously! so you want to allow only the elite members of theSecretSantaAdmin group on the domain to have access to the information. Furthermore,this information is SO secretive that you practice defense in depth andimplement Windows-integrated security for the ASP.NET application, but you alsoneed to make sure that the GetSecretSanta method can be executed only by theadmin group.

 

The code to protect the secret algorithms is actually verysimple. This is the complete GetSecretSanta method, which takes an employeename as input and returns that person s secret Santa:

 

Private Function GetSecretSanta(ByVal sEmpName As String) AsString

 Dim pp As NewPrincipalPermission(Nothing, "RIVERCHASERSecretSantaAdmin")

 pp.Demand()

 'Do the secret stuff

 Dim sSanta As String

 Select Case sEmpName

   Case "Carol"

      sSanta ="Don"

   Case Else

      sSanta ="Sorry! No Santa for that employee!"

 End Select

 Return sSanta

End Function

 

The important part of the code is these two lines:

 

Dim pp As New PrincipalPermission(Nothing, "RIVERCHASERSecretSantaAdmin")

pp.Demand()

 

The first line instantiates aSystem.Security.Permissions.PrincipalPermission class. This permissionclass does not derive from the CodeAccessPermission class because it interactsdirectly with the Windows security system. The first parameter in theconstructor used here takes a user name and the second is either a local ordomain group name. You can specify either parameter or both, so here the codeuses Nothing for the user name and a string for thedomain (RIVERCHASER) group.

 

After the permission object is instantiated, the call tothe Demand method is the step that enforces that this method is runable only bymembers of the specified group. At this point the Common Language Runtime (CLR)makes sure that the code is running by a member of the specified group. If itisn t, the code throws a catchable SecurityException with a message Requestfor principal permission failed. Robust applications would, of course, catchthat exception and handle it in some way.

 

You can do the same sort of demand declaratively using amethod attribute:

 

_

Private Function GetSecretSanta(ByVal sEmpName As String) AsString

 

In this case, you can use named parameters in VB.NET toavoid passing Nothing as the user name.

 

And that s all there is to it! The secrets of the secretSanta are safe for another year.

 

Next time I ll explore how to interact with permissionsfrom the calling code s point of view, then follow upwith an exploration of stack walks.

 

Don Kielyis senior technology consultant for Information Insights, a business andtechnology consultancy in Fairbanks, AK. E-mail him at mailto:[email protected].

 

 

 

 

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like