MSDN Magazine - February 2008 - (Page 53) Security Programming in SharePoint 2007 TED PATTISON Y ou may already know the fundamentals of security programming with Windows® and ASP.NET security, but how well do you know the security layer that Windows SharePoint® Services 3.0 (WSS) adds on top? In this month’s installment of Office Space, I will highlight new security terms and concepts that are introduced with WSS, and I will give you a jumpstart into the world of security programming using the WSS object model. I recommend that you download the sample project that accompanies this column and follow along with the code I will present throughout the rest of this column. The project has been configured to run a batch file after the build process, which will compile all of the project components into a WSS solution package and install the package on the local WSS farm. Once you have built the project and installed the solution, you can navigate to any site collection and enable the feature named Security Demo, which is scoped to the site collection. The Site Actions menu will then allow you to navigate to custom application pages, which have code behind them demonstrating WSS security programming techniques. class. The ASP.NET runtime dynamically creates different types of IPrincipal objects depending on whether the current user has authenticated using a Windows account or an FBA account: IPrincipal AspUser = HttpContext.Current.User; string AspUserName = AspUser.Identity.Name; The ASP.NET User object also provides a way to check to see if a user belongs to a particular role using the IsInRole method. For Windows users, the IsInRole method lets you see whether the current user is a member of an Active Directory group. If you are using FBA accounts along with an ASP.NET Role Provider, you can also use the IsInRole method to check whether the FBA user has been added to a specific ASP.NET role: IPrincipal AspUser = HttpContext.Current.User; if(AspUser.IsInRole(“Site Administrators”) { // perform privileged operation } External Security Principals and the SPUser Object Most security models are based on security principals. Each security principal represents either a user or a group. Users have accounts against which they authenticate. Once authenticated, each user takes on an identity. In the scenario where a user has authenticated against a Windows account, you can use the Microsoft® .NET Framework security classes in the System.Security namespace to retrieve an identity that points back to the specific Windows account and allows you to discover the user’s login name: WindowsIdentity identity = WindowsIdentity.GetCurrent(); string WindowsLogin = identity.Name; Using a WindowsIdentity, you can dynamically create a WindowsPrincipal, which will let you perform a test to see whether the current user is a member of an Active Directory® group or a local Windows group, like so: WindowsIdentity identity = WindowsIdentity.GetCurrent(); WindowsPrincipal principal = new WindowsPrincipal(identity); if( principal.IsInRole(@”LITWAREINC\AllFTE”) ){ // perform operation allowed for fulltime employees } ASP.NET supports both Windows authentication and Formsbased authentication (FBA). The User object in ASP.NET abstracts away the dependency on Windows accounts by modeling the User object on the IPrincipal interface instead of the WindowsPrincipal The act of authenticaWSS does not provide tion produces some form support for authenticating of a receipt that is used by the system at run time to users. Instead, it uses represent a user identity underlying components and to track membership supplied by various ASP.NET in groups or roles. When a authentication providers. user authenticates against a Windows account, the receipt of authentication is a Windows security token. When the user authenticates against an FBA account, the receipt of authentication is an HTTP cookie created by the ASP.NET runtime and a specific authentication provider. It’s important to understand that WSS does not provide support for authenticating users. Instead, WSS makes use of underlying authentication components supplied by the various ASP.NET authentication providers. The value that WSS brings to securing a site has to do with configuring authorization and access control. WSS makes it possible to track external security principals-such as Windows users, FBA users, Windows groups, and ASP.NET roles-within the scope of a site collection. With WSS, you can also configure the permissions that are assigned to these external principals, which, in effect, grant users permissions to access securable WSS objects such as sites, lists, items, and documents. Note that the site collection plays a significant role when you’re configuring authorization and access control. WSS considers each site collection to be its own separate island when it comes to trackfebruary2008 53
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.