Sunday, 19 February 2012

SharePoint Server 2010 Authentication Methods

SharePoint Server 2010 provides a flexible and extensible authentication system, which supports authentication for identity management systems that are based or are not based on the Microsoft Windows operating system. By integrating with ASP .NET pluggable authentication, SharePoint Server 2010 supports a variety of authentication scenarios, including:
  • Using standard Windows authentication methods.
  • Using a simple database of user names and passwords.
  • Connecting directly to an organisation’s identity management system.
  • Using two or more methods of authentication for accessing partner applications (such as, connecting to your partner company’s identity management system for authenticating partner employees while using Windows authentication methods to authenticate your internal employees).
The following are the lists of authentication methods:
  • Claims: Claims authentication for SharePoint Server 2010 is built on the Windows Identity Foundation, which is a set of .NET Framework classes that are used to implement claims-based identity.
  • Windows: The standard IIS Windows authentication methods are supported.
    Below are the following  types of windows authentication:
    • Anonymous
    • Basic
    • Digest
    • Certificates
    • Kerberos (Integrated Windows)
    • NTLM (Integrated Windows)
  • Forms-based authentication (FBA): SharePoint Server 2010 adds support for identity management systems that are not based on Windows by integrating with forms-based authentication. Forms-based authentication enables SharePoint Server 2010 to work with identity management systems that implement the MembershipProvider interface. You do not need to rewrite the security administration pages or manage shadow Active Directory directory service accounts.
    Below are the following  types of FBA authentication:
    • Lightweight Directory Access Protocol (LDAP)
    • SQL database or other database
    • Other forms-based authentication solutions

What is Content Types and Site Columns?

Content types and site columns are the foundational elements of SharePoint, but they often get misused. Whether it’s creating too many content types, not enough, or recreating site columns that are already available out of the box, it is critical to remember some key aspects when instituting and managing these items:

Content Types
Content types are a core organizational feature of SharePoint 2010. They are designed to give users the ability to organize SharePoint content in a centralized and meaningful manner. Site columns (metadata) can be encapsulated within a content type to allow for reusable structure or independently added to sites and lists.
At its most basic level, a content type is a collection of settings which can be applied to content. They are reusable since content types are independent of sites and lists. A content type includes site columns to define the desired information. Example: The Task content type includes site columns for Task Status, Start Date and Due Date where the Schedule content type includes site columns for Location, Start Time and End Time. Using these content types as a template when a new task or event list needs to be created is much more efficient than rebuilding separate lists from site columns.

Sample Issue Content Type
SharePoint 2010 Content Type Information

Site Columns
Site columns are similar to content types in that they are centrally manged and can be added to sites and lists. They differ in that the information in a site column is focused to a single definition of data while content types enscapulate multiple site columns and definitions of data. Example: A site column named Department is created as a single line of text for users to enter their department name and a content type is created named Projects which includes the site columns of Department, Project Name and Project Due Date.
Site columns can contain multiple types of information, ranging from a Single line of text to Managed Metadata. It is important to note the difference between metadata and managed metadata. Site columns are referred to as metadata since they represent an attribute a user wants to manage. Example: The site column of Department is an attribute that can be reused in multiple lists.

Sample Site Column Information Options
SharePoint Site Column Options

Managed Metadata
Managed metadata is collection of centrally managed terms that can be used as attributes for SharePoint items. Defining a site column to use Managed Metadata for information is a powerful tool for assigning attributes. Example: Creating a Department site column, based on a managed metadata term set containing all of the department names in an organization, allows users to select the correct department and reduces typographical errors and non relevant data. It also provides for the proper tagging of documents for routing and search purposes.

Content Type Hub
Content types can also be stored in a Content Type Hub for centralized management of content types across Site Collections and Web Applications. This features utilizes the Managed Metadata Service and allows Site Collections to subscribe to any published content types. Any changes to published content types will be updated in the subsribing Site Collections. Since managed metadata can be created as a site column within a content type, terms can be globally syndicated across Site Collections and Web applications.

Content Type and Site Column Suggestions
Centrally creating and managing relevant content types and site columns is critical to ensuring consitent attributes across SharePoint. The following points offer guidance on maintaining an organized content type and site column structure:
Review the built in content types and site columns before creating new ones
SharePoint 2010 comes with many built in content types and site columns that may meet the needs of your structure. In planning your SharePoint structure, review the built in options before creating any new content types or site columns. New content types will be based on content types that already exist (parent content types). This allows for a pre organized template to begin the content type creation process. Example: Creating a new content type of “Proposal Document” based on the parent content type of “Document” will provide the necessary settings for referencing a document template and include the site columns of Name, Title and Keywords.

Carefully plan the information contained in content types and site columns and be prepared to refine metadata
Creation of new content types and site columns should not be done on an ad hoc basis. Take the time to discover what metadata is relevant to your organizations data collection and referencing needs. Creation of underutilized site columns (metadata) and content types places an unnecessary data entry burden on users which can lead to poor adoption of SharePoint and creation of non-relevant data.

Centrally manage content types and site columns
Site columns (metadata) can be created at the list or document library level. Site columns created in this manner exist only at the list level in which they were created and not within the confines of content types or the centrally managed Site Column Gallery. This becomes problematic when managing consistent metadata as these site columns cannot be reused. It is highly recommended to create new site columns within the Site Column Gallery and add these site columns to the content types associated with the preferred list or document library. Changes made to centrally managed content types will propagate down to the list and document libraries they have been added to.
A SharePoint implementation with multiple Site Collections or Web applications would benefit from the use of a Content Type Hub. This will allow for central management of “global” content types across the Enterprise for Site Collections that are subscribed to published content types. Leveraging this feature in tandem with managed metadata creates globally syndicated terms. Example: A content type containing a managed metadata site column, based on a product term set, is published. The list of products can now be reused as an attribute across the organization.

SharePoint 2010 Web Parts vs. Visual Web Parts

I have read a lot of SharePoint documentation and articles recently, and one confusing point that kept getting glossed over was whether there was a difference between what was called a “Visual” Web Part and a Web Part by any other name.
The answer is, there is a difference, but not in the .NET type. There is a difference in how the part is implemented and its project type in Visual Studio. The short answer is that a Web Part is “visual” if its implementation includes an ASP.NET user control, i.e. an .ascx file. Creating a project of type “Visual Web Part” from the Visual Studio project wizard creates a project that looks like this:

Notice the automatically-created .ascx user control. Indeed, the code in the Web Part is the same as we would find on a normal part, but in the implementation the user control is instantiated programmatically like this:
01public class VisualWebPart1 : WebPart
02{
03    private const string _ascxPath =
04        @"~/_CONTROLTEMPLATES/VisualWebPartProject2/VisualWebPart1/VisualWebPart1UserControl.ascx";
05
06    protected override void CreateChildControls()
07    {
08        Control control = Page.LoadControl(_ascxPath);
09        Controls.Add(control);
10    }
11}
Trying to deploy this project as a sandboxed solution will fail, since user controls violate the constraints placed on code that runs in the sandbox. There is nothing intrinsically about the code that would prevent its installation as a sandboxed solution, but it will fail when the solution is activated.

Changing a Visual Web Part to a regular Web Part

We can change the Web Part type by manually editing the .spdata file in the project. Visual Studio won’t allow direct access to this file, so we’ll have to browse to it on the filesystem and edit it in notepad.
01<?xml version="1.0" encoding="utf-8"?>
02<ProjectItem Type="Microsoft.VisualStudio.SharePoint.VisualWebPart" DefaultFile="VisualWebPart1UserControl.ascx" SupportedTrustLevels="FullTrust" SupportedDeploymentScopes="Site" xmlns="http://schemas.microsoft.com/VisualStudio/2010/SharePointTools/SharePointProjectItemModel">
03  <Files>
04    <ProjectItemFile Source="Elements.xml" Target="VisualWebPart1\" Type="ElementManifest" />
05    <ProjectItemFile Source="VisualWebPart1.webpart" Target="VisualWebPart1\" Type="ElementFile" />
06    <ProjectItemFile Source="VisualWebPart1UserControl.ascx" Target="CONTROLTEMPLATES\VisualWebPartProject2\VisualWebPart1\" Type="TemplateFile" />
07  </Files>
08  <SafeControls>
09    <SafeControl Name="SafeControlEntry1" Assembly="$SharePoint.Project.AssemblyFullName$" Namespace="VisualWebPartProject2.VisualWebPart1" TypeName="*" IsSafe="true" IsSafeAgainstScript="false" />
10  </SafeControls>
11</ProjectItem>
We are interested only in this line:
1<ProjectItem Type="Microsoft.VisualStudio.SharePoint.VisualWebPart" DefaultFile="VisualWebPart1UserControl.ascx" SupportedTrustLevels="FullTrust"
We can change the Type from VisualWebPart to WebPart and SupportedTrustLevels from FullTrust to All.
The resulting code looks like this:


1<ProjectItem Type="Microsoft.VisualStudio.SharePoint.WebPart" DefaultFile="VisualWebPart1UserControl.ascx" SupportedTrustLevels="All"
Once the change is made, reload the project in Visual Studio, and its type should be recognized as a normal web part. Be sure to remove the user control before attempting to deploy as a sandboxed solution!