Yesterday I attended an excellent MSDN event on security related topics. Glen Gordon presented two sessions, Writing Secure Code – Threat Defense and Implementing Application Security Using The .Net Frame (Presentations available here). While I'm finding I can always enjoy and take away something useful from Glen’s presentations, I really think Microsoft deserves some credit for getting the word out to the development community on security. Yes, they have had their own problems in the past with their own code, but they’re on a mission to make sure that none of us take security for granted and are getting the word out quite effectively through webcasts, MSDN events, and I’m sure we’ll hear even more great information at DevDays.
Glen commented on his blog following the presentation on how a number of developers were suddenly concerned about vulnerabilities in their code. I think it’s great that Microsoft is taking such a strong leadership role in the development community.
One of the cool things I started playing with recently following a webcast that Glen also addresses is the use of WindowsIdentity and WindowsPrinciple objects for validation of users and their roles. This makes taking advantage of windows security a snap! Here’s how easy it is to check to see which roles the user running the code belongs to:
WindowsIdentity myIdent = WindowsIdentity.GetCurrent();
WindowsPrincipal myPrin = new WindowsPrincipal(myIdent);
Array wbirFields = Enum.GetValues(typeof(WindowsBuiltInRole));
StringBuilder sb = new StringBuilder();
sb.Append("BuiltIn Roles for ");
foreach (object roleName in wbirFields)
sb.Append(myPrin.IsInRole((WindowsBuiltInRole)roleName) + "\n");
sb.Append(roleName + " Could not obtain RID for this role.\n");
You can also make use of the myPrin.IsInRole((“MyRoleString“)to check and see if the user is in a custom role.
Note When testing for newly created role information, such as a new user or a new group, it is important to log out and log in to force the propagation of role information within the domain. Not doing so can cause the IsInRole test to return false.