DotNetIdeas

Avoid Polluting SharePoint farm

noreply@blogger.com (DotNetIdeas) — Fri, 13 Aug 2010 21:45:00 +0000

A developer can easily pollute a SharePoint farm by exposing components to unintended audience as the following.

In MOSS, you cannot target a feature to a specific site, site collection or web application. A deployed feature is visible to SharePoint administrators everywhere in the SharePoint Farm even though the feature should be used in a very specific context.
Deploying a Dll to GAC makes the Dll fully trusted and accessible to the entire server. Any code running on the server may use the Dll.
A user control deployed to the ControlTemplates directory can be used by any ASP.NET components deployed to the farm.
An application page deployed to the Layouts directory is visible to end users from any SharePoint site in the Farm. Most importantly, you cannot manage the security permission on the Page easily. The page will observe the default security permission for all the pages in Layouts directory. Also, the code behind dll for an application page has to have full trust since everything in Layout has full trust. This violates the basic security principle.

Item 4 will do the most damage since end users will see the pollution right way and it is not easy to apply security to the page to fix it. Item 1 will only affect SharePoint administrators. Item 2 and 3 will affect developers and infrastructure team.

However, Item 4 is the least aware among developers since it is just so easy.

An alternative to create an application page is to deploy the page to a document library in the site needing the page. Because it is in a document library, you can apply different security policies to the page. So only the right people can access the page with the right permissions. Also, the code behind dll of it can be deployed to bin directory without full trust since it is not in Layouts directory. Obviously, this approach solves all the issues listed in Item 4.

Access external data in SharePoint with BDC (business data catalog), SSO (Single Sign On) and WCF (Windows Communication foundation)

noreply@blogger.com (DotNetIdeas) — Wed, 24 Feb 2010 18:00:00 +0000

High Level Summary

Accessing external systems from SharePoint portals is a typical integration scenario. One reality that has not changed is that there are three basic components to any interoperability scheme.

Communication–You must be able to connect and communicate with the foreign system, either through code or through infrastructure.
Identity Management–You must have some way to authenticate users against the foreign system.
Composition–You must be able to assemble discrete pieces of data (from tables, function calls, and so on) into an entity that is meaningful and useful to business users.

There are challenges in all three of these activities, regardless of what you are connecting.

The architecture tackles the four issues elegantly. WCF provides the communication. Single Sign On provides the Identity management. Business data catalog allows different ways to compose such as DataViewWebPart, BDC object model, search and out-of-box BDC web parts.

Comparing with directly accessing WCF web service, my favorite argument to support this architecture is that BDC is a layer of security boundary in addition to its support to search. BDC allows you to authorize the access to BDC entities through Shared Service web pages. With direct WCF access, there is no easy way to achieve this level of seamless integration and flexibility to control the authorization.

Another advantage of this architecture is to let BDC access external data through SSO, which allows the management of identities in SharePoint central admin web pages. Invoking WCF or Web Service directly from code will run into the famous double hop issue in a distributed environment unless you hard code the user credentials. The matter will be even more complicated if you use SharePoint Form Authentication. BDC has very nice integration with SSO so it is a very nature approach to marry those two technologies together for accessing external data.

Implementation Details

Notice, it is not a step by step tutorial. Instead, it covers important ideas and possible catches during implementation.

Tools

Visual Studio 2008 for WCF development
Microsoft Application Definition Designer for BDC definition.
Microsoft MOSS server for SSO and BDC configuration

Ideas/Catches

Use BDC to control the authorization. In the home page of the ShareService administration web site, you will see the “Business data catalog permission” at the bottom-right corner as the following

Use WCF to encapsulate your external system. BDC supports “basichttpbinding” only. The following is a sample web.config. Here is one of the biggest catch. If running the WCF inside VS2008, use “NTLM”. After deploying the WCF to production, use “Windows”. It appears that VS2008 debug web server has different behavior in terms of WCF authentication. Also, in VS2008, you cannot test WCF authorization through [PrincipalPermission(SecurityAction.Demand, Name = “”)], it won’t work.

<service behaviorConfiguration="WindowsAuthorizationBehavior"
         name="BDCContractImplementation">
    <endpoint   address="" 
                binding="basicHttpBinding" 
                bindingConfiguration="WindowsAuthenticationBinding"
     contract="IBDCContract">
    <identity>
      <dns value="host" />
     </identity>
    </endpoint>
 </service>
 <behaviors>
       <serviceBehaviors>
          <behavior name="WindowsAuthorizationBehavior">
             <serviceMetadata httpGetEnabled="true" />
             <serviceDebug includeExceptionDetailInFaults="true" />
             <serviceCredentials>
                <windowsAuthentication includeWindowsGroups="true" allowAnonymousLogons="false" />
             </serviceCredentials>
             <serviceAuthorization principalPermissionMode="UseWindowsGroups"
                impersonateCallerForAllOperations="false" />
          </behavior>
      </serviceBehaviors>
 </behaviors>
<bindings>
      <basicHttpBinding>
        <binding name="WindowsAuthenticationBinding" 
                 maxBufferSize="2147483647"
                 maxReceivedMessageSize="2147483647">
          <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Ntlm"/> <!-- works in VS2008 debug -->
            <!--<transport clientCredentialType="Windows" /> --> <!-- works after deploying to IIS -->
          </security>
        </binding>
      </basicHttpBinding>
 </bindings>

The catch of the return value from IDEnumerator in BDC. If the ID is of type string, you can not return list<string> from IDEnumerator. You must implement a simple class to encapsulate the ID; otherwise, for some reason, Microsoft Application Definition Designer won’t able to handle the method

/* The small class to encapsulate the string */
[DataContract]
 public class MeetingID
 {
        [DataMember]
        public string MeetingIDStr { get; set; }
 }
[ServiceContract]
 public interface IMeetingBDC
 {
        [OperationContract]
        List<Meeting> GetAllMeetings(string filter);
        [OperationContract]
        Meeting GetMeetingSpecificFinder(string meetingId);
        [OperationContract] /* the signature for IDEnumerator */
        List<MeetingID> GetMeetingIdEnumerator();
 }

BDC configuration using SSO. Copy paste and modify the following code:

<LobSystemInstance Name="BDCMeeting_Instance">
      <Properties>
        <Property Name="LobSystemName" Type="System.String">LobMeeting</Property>
        <Property Name="WebServiceAuthenticationMode" Type="Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.WebService.HttpAuthenticationMode">WindowsCredentials</Property>
        <Property Name="SsoProviderImplementation" Type="System.String">Microsoft.SharePoint.Portal.SingleSignon.SpsSsoProvider, Microsoft.SharePoint.Portal.SingleSignon, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Property>
        <Property Name="WebServiceSsoApplicationId" Type="System.String">your_sso_application_id</Property>
      </Properties>
</LobSystemInstance>

SharePoint Analysis and Design Tips.

noreply@blogger.com (DotNetIdeas) — Mon, 17 Aug 2009 14:41:00 +0000

Object-Oriented Analysis and Design is a relatively mature technique. We call it Object-Oriented because the technique is to implement various requirements with objects in code. Likewise, In SharePoint Analysis and Design, we map requirements to SharePoint components such as web parts, lists, document libraries, views, site columns, content types, page layouts, info path forms, application pages, excel services, business catalogs, user profiles, my sites, site maps and so on.
The article is not to establish a methodology. It tries to explain a couple of experiences that may help in SharePoint Analysis and Design.
1. Map business requirements to technical solution as early as possible.
In object-oriented design, separating business domain requirements and technical solutions is a good practice. Technical solutions should not impact collecting business requirements if possible. However, this separation of requirement and solution is what SharePoint Analysis and Design should avoid. Considering technical solution at early stage will provide the following benefits:

Make business users aware what cannot be done with SharePoint's out-of-box features. Business users expect SharePoint to do Anything through configuration, but custom development is inevitable for most of the enterprise-level MOSS applications. Custom development demands more efforts, and we need to inform those efforts to customers as early as possible.
Give SharePoint developers the opportunities to explain the out-of-box features that will meet or exceed the same business goals with different business processes. For example, the business goal of sharing knowledge and experience among employees can be archived by using out-of-box wiki library. Therefore, the original use cases collected from customers for achieving the same business goal will be altered according to the wiki libraries' behavior.

2. Strive for configurable/customizable solutions.
SharePoint allows end users to customize solutions without going through development cycles. End users may customize lists, document libraries, site pages, site master pages, define security groups and permission levels, etc; They may publish InfoPath forms and excel sheets, and create ad-hoc reports and dashboards using PerformancePoint. To take advantage of those features while designing SharePoint solution, consider separate the responsibilities of developers and end users. Both end users and developers have the responsibilities to contribute to SharePoint solutions. For example, in an InfoPath form, developers implement the web services for InfoPath to connect to and configure the SSO application while end users are responsible to create the InfoPath connections to the web services using SSO authentication. The relationship between developers and end users is very much like how frameworks' developers are related to the developers who use the frameworks. Basically, developers should deal with more difficult tasks and expose their work through interfaces to end users. The interfaces in SharePoint context, which is very different from the .NET interfaces, are in the formats of InfoPath connection, SSO, Content Type, Page Layout, etc.

SharePoint Workflow - Use IListItemService to manipulate list items other than the workflow list items.

noreply@blogger.com (DotNetIdeas) — Sun, 09 Aug 2009 21:24:00 +0000

SharePoint workflows can use OnWorkflowItemChanged and OnWorkflowItemDeleted activities to capture the "changed" and "deleted" events for the list items associated with the SharePoint workflow instances. To capture the "changed" and "deleted" events for the list items not associated with SharePoint workflow instances, we need to use SharePoint workflows' IListItemService.

IListItemService is one of four ExternalDataExchange services - IListItemService, ISharPointService, ITaskService and IWorkflowModificationService - registered by SharePoint runtime. IListItemService provides the methods and events to handle any list items in the SharePoint Site Collection where a workflow instance is running. To study the interface, I developed two workflows to illustrate two different scenarios using IListItemService.

Scenario 1: A workflow needs to capture the OnItemChanged event of a pre-existing list item.

To test the scenario, I created two SharePoint lists:

workflowlist: it has a workflow association with the testing workflow and one item called "workflow item".
anotherlist: the changed events of its items should be captured by the testing workflow associated with workflowlist above. The list's listid is 7c455073-56ce-4ecd-bfa8-2923fc521b9e and it has one item called "another list item". The id of the item is 1.

The following is the design view of the testing workflow:

The workflow includes three activities:

1. OnWorkflowActivated activity is required by all the SharePoint workflows.

2. InvokeIntializeForEvent is a subclass of CallExternalMethodActivity with the following parameters:

The activity will invoke the InitializeForEvent method defined in the IListItemService interface. The signature of the method is:

[CorrelationParameter("id"), CorrelationParameter("itemId"), CorrelationParameter("listId"), ExternalDataExchange, SharePointPermission(SecurityAction.LinkDemand, ObjectModel=true), SharePointPermission(SecurityAction.InheritanceDemand, ObjectModel=true)]
public interface IListItemService
{
    ......
    void InitializeForEvent(Guid id, Guid listId, int itemId);
}

Parameter Name	Parameter Value	Description
id	f1bb0cd5-e470-4e70-90ea-e37525a3662a	A GUID generated at development time
itemId	1	The id for the “another list item” list item in the "anotherlist" SharePoint list
listId	7c455073-56ce-4ecd-bfa8-2923fc521b9e	The id of the "anotherlist" SharePoint list

3. handeItemChangedEvent is a HandleExternalEvent activity with the following parameters:

This activity will wait on the OnItemChanged event defined in IListItemService interface. It should use the same Correlation Token, newtoken, for the activity prior to it.

We can test the workflow with the following steps:

1. Start the workflow for the "workflow item” list item in the "workflowlist" SharePoint list. The workflow should stop at "in progress" status since it is blocked and waiting for the OnItemChanged event.

2. Modify the "another list item" list item in the "anotherlist" list and change its title to "another list item changed".

3. Go back to the workflow list. Its workflow status is changed to complete since step 2 modifies the list item and trigger OnItemChanged event.

The solution demonstrates the following key points:

IListItemService.InitializeForEvent should be invoked to establish the correlation token for a list item before you can capture the event for the list item. (You may use IListItemService.UpdateListItem, CheckInListItem, etc instead. ).
listId and itemId for InitializeForEvent must match the ids of the SharePoint list and list item.
id for InitalizeForEvent can be any uniquely generated GUID. It does not need to match any ids.

Scenario 2: A workflow needs to create an new list item and wait on its changed events.

In this case, you need to use IListItemSevice.CreateListItem to create the list. However, you cannot use the correlation token for CreateListItem because the "itemId" parameter is unknown while invoking the method. You can get the itemId as a "returnvalue" in your workflow instead.

So, here is the solution:

1. Add a CallExternalMethod activity to invoke the "CreateListItem" method. The activity should include an event handler for MethodInvokded event. In the event handler, get the return value and assign the value to a member variable to the workflow.

protected override void OnMethodInvoked(EventArgs e)
{
   this.ItemId = (int)base.ParameterBindings["(ReturnValue)"].Value;
}

2. Add an InitializeForEevnt activity to invoke the "InitializeForEvent" method. Make sure use the ItemId returned by CreateListItem. This activity should create a new token, which is different from the one for "CreateListItem". The token for "CreateListItem" is basically not used any where.

3. Add an HandleExteranlEvent activity as in Scenario 1.

Why are we getting "(1385) System.ComponentModel.Win32Exception: Logon failure: the user has not been granted the requested logon type at this computer"

noreply@blogger.com (DotNetIdeas) — Fri, 31 Jul 2009 20:02:00 +0000

SharePoint InfoPath Service can use SSO to access external resources such as web services and SQL server databases.
As explained at MSDN site, an InfoPath form can access external data sources through connection files. Behind the scene, the InfoPath runtime will get the credential to impersonate through SSO API and invoke LogOnUser function with the credential if Windows authentication is used.
You may run into the following exception while running an InfoPath form with SSO connections:
LogonUser failed for user 'domain\username' (1385) System.ComponentModel.Win32Exception: Logon failure: the user has not been granted the requested logon type at this computer
If you Google the exception for solution, you may find the advice to give the delegated user “Allow Log on locally” windows right. But, it won’t help. Even if you add the user to the local administrator group, it still doesn’t work. To solve this issue, we need to understand how InfoPath Service runtime impersonates with the credential configured in SSO. Writing a web part using SSO API and LogOnUser will help us to understand what is happening inside the InfoPath runtime.
The following code segment explains the three steps to use SSO in a web part:

Retrieve the credential used to connect to the external database through SSO API;
Impersonate the credential using LogonUser;
Create a ADO connection to the database using Integrated Security;

//*******************************************************************

//Step 1: Get the account for connecting to database from SSO API

string[] strCredentialData = null;

//Credentials.Get Credentials is a SharePoint SSO API

Credentials.GetCredentials(1, "eex", ref strCredentialData);

string strUserName = strCredentialData[0];

string[] domainUserName = strUserName.Split('\\');

string strPassword = strCredentialData[1];

//***********************************************************************

//Step 2: Use LogOnUser to impersonate with the account

bool result = LogonUser(domainUserName[1], domainUserName[0],

strPassword,

LogonSessionType.Batch,

LogonProvider.Default,

out token);

WindowsIdentity id = new WindowsIdentity(token);

impersonatedUser = id.Impersonate();

//************************************************************************

//Step 3:Use ADO.NET with Integrated Security to retrieve data from the external database.

string resultFromDb = null;

using (SqlConnection connection = new SqlConnection("Integrated Security=SSPI;Initial Catalog=external_test;Data Source=sqlserver"))

connection.Open();

SqlCommand command = new SqlCommand("select * from simple", connection);

using (SqlDataReader reader = command.ExecuteReader())

reader.Read();

resultFromDb = (string)reader[0];

connection.Close();

The code above explains how, behind the scene, SharePoint Form Service is using LogOnUser to impersonate an account. So the reason we got the "LogonUser failed for user 'domain\username' (1385) System.ComponentModel.Win32Exception: Logon failure: the user has not been granted the requested logon type at this computer" is that SharePoint Form Service invokes LogonUser with Batch logon session type (the fourth parameter to LogonUser). Therefore, you need to configure the the security policy of your Web Front End to give the delegated user “Log on as Batch” right. The following screen shot demonstrates the configuration.

Understand MOSS Search Run Time Architecture

noreply@blogger.com (DotNetIdeas) — Thu, 23 Jul 2009 21:14:00 +0000

Understanding SharePoint Search Run Time Architecture is very helpful in planning/configuring SharePoint farm and troubleshooting Kerberos authentication. I recently read the following paragraph from Microsoft Web Site regarding SharePoint search planning:

In Office SharePoint Server 2007, the index role is associated with a Shared Services Provider (SSP). The index role builds one index per SSP. One index server can be associated with multiple SSPs. However, indexes across SSPs cannot be combined. You can deploy multiple index servers to improve capacity. In this case, each index server is associated with different SSPs. Unlike the Windows SharePoint Services 3.0 search role, content indexes produced by the Office SharePoint Server 2007 index role are continuously propagated to all servers that host the query role in a farm. Consequently, the output of the Office SharePoint Server 2007 index server role (that is, the index) is considered redundant if the query role is deployed to more than one server computer.

Let me explain this in detail.

What are index role, query role, index server and query server?

Index role is a logic role or responsibility that crawls contents and build index files. Query role is a logic role or responsibility that returns query results. Index Server/Query Server is an Office SharePoint Server Search Windows Service instance running on a server in the SharePoint Farm. The following picture shows the Services Console of a SharePoint Server:

An Office SharePoint Server Search Windows Service Instance can be configured to run as an index role, a query role or both. If an instance of MOSS Windows Search Service is configured as Index role. It is called Index Server. The same applies to the Search Role.

To start and configure a Index or Search server, open SharePoint Central Administration. Click the operation tab and then click "Services on the Server", the following window displays:

Click the "Office SharePoint Server Search" link. The screen to configure the Server Role for the Office SharePoint Server Search displays:

In this page, you can determine what roles the instance of Office SharePoint Server will play by selecting the check boxes at the top of the page.

We know how to create Index and Search server for a SharePoint farm. In a SharePoint Farm, we can have multiple SSPs. Each SSP may have different contents to search. The question is which SSP the index and Search server will work for. To answer the question, we need to study another setting. While creating a SSP, you will be ask to choose an index server:

The "Index Server" drop down list will allow you to choose which index server to use for the SSP. However, there is no selection for a Search Server. Therefore, we know:

A SSP can have one and only one index server.
A Search Server will serve for all the SSPs created in the farm.

Now, let us re-visit the paragraph from Microsoft Web Site using the knowledge we just learned:

In Office SharePoint Server 2007, the index role is associated with a Shared Services Provider (SSP). The index role builds one index per SSP. One index server can be associated with multiple SSPs. However, indexes across SSPs cannot be combined. You can deploy multiple index servers to improve capacity. In this case, each index server is associated with different SSPs.

It is in line with "A SSP can have one and only one index server"

Unlike the Windows SharePoint Services 3.0 search role, content indexes produced by the Office SharePoint Server 2007 index role are continuously propagated to all servers that host the query role in a farm.

It is in line with "A Search Server will serve all the SSPs created in the farm

Consequently, the output of the Office SharePoint Server 2007 index server role (that is, the index) is considered redundant if the query role is deployed to more than one server computer.

It basically says that you can scale out for Search Server. However, you cannot scale out for Index Server inside one instance of SSP.

Interesting observation on SharePoint Security

noreply@blogger.com (DotNetIdeas) — Sat, 18 Jul 2009 13:39:00 +0000

The article lists some SharePoint Security related facts/experience that may be helpful. Please add your comments if you think the list should expand

Anonymous Users can add/edit/delete list items. However, they can never add/edit/delete document library items even though they can view document library items.
It is not possible to make some of the items in a list/document library accessible to anonymous users while other items not accessible. All the items in a list/document library must have the same accessibility for anonymous users.
You cannot add a Windows Group to Site Collection Administrators. You can only add individual users. It is by design. In my opinion, however, it is not convenient for administration.
A common misconception is that a user in the Site Owner group can access all the contents in a site. In theory, you must check item level permission for all the items in all the lists to make sure a user can access all the contents in a site. To be complete, you need also to check the Security Policy for the web application. Never assume a site owner can do anything.
Limited Access Permission Level is to be added by SharePoint automatically. For example, assuming a user does not have any permission in a SharePoint site, if you add an item level read permission to the user for an item of a list. The SharePoint will add Limited Access Permission Level to the user at the list and the site level automatically.
SharePoint does not have the finest permission granularity. For example, it is not possible to have one user to have edit site title and image permission and the other to have delete child sub sites permission. This is because "Manage Web Site" permission includes both edit site title/image and delete child sub sites. This lack of finest permission does cause problem in practice since you have to assign the same people to perform two very different categories of administrative tasks.
...... more to come

SharePoint Security for the contents in _layouts, _controltemplates and _vti_bin directories in the context of SharePoint NTLM authentication

noreply@blogger.com (DotNetIdeas) — Fri, 17 Jul 2009 03:00:00 +0000

A SharePoint web application can be accessed through multiple IIS web sites with different authentication such as NTLM, Kerberos and Form. It is important to differentiate a SharePoint Web Application and the IIS Web Sites accessing the SharePoint Web Application. Typically, each IIS Web Site accessing a SharePoint Web Application will correspond to a zone in SharePoint's Alternate Access Mapping. Each zone has a public address and multiple internal addresses. The multiple internal addresses typically map to addresses for load balancing.

The article discusses the authorization on accessing the files in _layouts (application pages and resources), _controltemplates (user controls and resources) , _vti_bin ( web services) in the context of an IIS Web Site or Zone configured with NTLM authentication.

If an IIS Web Site to access a SharePoint Web application is configured with NTLM authentication, the authorization to the contents in those directories is mostly determined by ASP.NET 2.0 Windows authentication mechanism.

When a SharePoint IIS web site is configured with NTLM authentication, the web.config file of the web site has "Windows" as its authentication method. In Windows authentication, Asp.NET 2.0 actually relies on IIS to perform authentication (basic, digest and integrated). The IIS will produce a security token after the authentication and then pass the security token to ASP.NET. Then, ASP.NET will perform two types of authorization using the identity encapsulated in the security token.

URL authorization (You can edit the web.config files in _layouts, _controltemplates and _vti_bin to define URL authorization)
ACL authorization. This authorization does not occur for Form authentication.

It is important to realize both authorizations will apply. Therefore, even if a user has URL authority to access an ASPX or image file, he/she may still not be able to access them due to the failure of ACL authorization.

Notice, the "impersonate" will not affect the above process. It will only affect when you write server side code, for example, when you try to open a local file in your web part. SharePoint always has "impersonate" as true.

In SharePoint NTLM (not Form) authentication, accessing the files and resources in _layouts, _controltemplates and _vti_bin pretty much follows the two authorization methods (URL and ACL) of ASP.NET 2.0. However, there is just one exception to the rule. For ASPX pages in the layouts directory that inherits from out-of-box class Microsoft.SharePoint.WebContorls.LayoutsPageBase, the class will check if the current SharePoint user has "View Application Pages" permission. So, it is the third authorization methods applied to those pages.

Now add anonymous users to the mix. Like authenticated users, the authorization for anonymous users is pretty much determined by ASP.NET 2.0 with one exception that is the pages inheriting from Microsoft.SharePoint.WebContorls.LayoutsPageBase. There are some interesting things worth metioning:

URL authorization will use question mark "?" to denote anonymous users;
ACL authorization will use IUSR_MachineName account. (This account is configurable in IIS);
Anonymous users can never load pages inheriting from Microsoft.SharePoint.WebContorls.LayoutsPageBase;

The first two are just typical ASP.NET 2.0 way of handling security. The third one is really a surprise. SharePoint anonymous users by default should have "limited access" permission level that should have "View Application Pages" permission. However, anonymous users still cannot access the pages inheriting from Microsoft.SharePoint.WebContorls.LayoutsPageBase even with the "View Application Page" permission. I could not explain why and just remember that this as an exceptional scenario. To expose SharePoint Application Page to anonymous users, do not use Microsoft.SharePoint.WebContorls.LayoutsPageBase as its base page class.

Inside SharePoint SafeControl

noreply@blogger.com (DotNetIdeas) — Thu, 02 Apr 2009 23:40:00 +0000

I saw quite a few times that while seeing security exception thrown from SharePoint, the first reaction is to add a SafeControl entry. SharePoint will tell you very clearly if you need to add any SafeControl entry in your Web.Config. Typically, you should see the error message similar to the following:

Parser Error

Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: The control type 'Dummy.DummyUnsafeWebPart' is not allowed on this page. The type is not registered as safe.

If you have not seen the message, do not try to add any SafeControl. SafeControl is a SharePoint-special security mechanism. A common MISTAKE is to assume a Dll will have full trust if the Dll is added to the SafeControl list.

The SafeContol entries are checked by SharePoint parser to make sure Controls are “safe” to be placed in a page declaratively. It is important to know that only SharePoint Parser honors SafeControl. After parsing stage, SafeControl is out of Picture. This can be explained by the following sample code:

[ToolboxData("<{0}:DummySPWebPart runat=server></{0}:DummySPWebPart>")]

public class DummySafeWebPart : WebPart

    protected override void CreateChildControls()

        this.Controls.Clear();

        this.Controls.Add(new Dummy.DummyUnsafeWebPart());

[ToolboxData("<{0}:DummyWebPart runat=server></{0}:DummyWebPart>")]

public class DummyUnsafeWebPart : WebPart

    protected override void RenderContents(HtmlTextWriter output)

        output.Write("Hello World");

The code shows the implementation of two web parts, DummySafeWebPart and DummyUnsafeWebPart. DummySafeWebPart just creates and adds an DummyUnsafeWebPart to its Children’s collection. Add an SafeControl entry to Web.Config for DummySafeWebPart. Now, testing the following two scenarios:

Scenario 1: A sharepoint page containing DummySafeWebPart only

<%@ Page Language="C#" %>

<%@ Register assembly="SPDummy" namespace="SPDummy" tagprefix="SPDummy" %>

<html dir="ltr">

<head>

<META name="WebPartPageExpansion" content="full">

</head>

<body>

<head>

<META name="WebPartPageExpansion" content="full">

</head>

<form id="form1" runat="server">

<SPDummy:DummySafeWebPart runat="server" />

</form>

</body>

</html>

Open the page in a Brower, it works fine.

Scenario 2. A sharepoint page containing DummyUnsafeWebpart only:

<%@ Page Language="C#" %>

<%@ Register assembly="Dummy" namespace="Dummy" tagprefix="Dummy" %>

<html dir="ltr">

<head>

<META name="WebPartPageExpansion" content="full">

</head>

<body>

<head>

<META name="WebPartPageExpansion" content="full">

</head>

<form id="form1" runat="server">

<Dummy:DummyUnsafeWebPart runat="server"  />

</form>

</body>

</html>

Open the page in a Brower, it throws exception:

The two testing scenarios show that an “unsafe” control can be loaded by a “safe” control in sharepoint. However, if you place the “unsafe” control declaratively in a sharepoint content page, sharepoint will complain. This is becanse SharePoint Parser can not see the loading of unsafe control inside safecontrol. Parser can only see whatever controls your place declaratively in a page.

SharePoint, Trust Level and Code Access Security

noreply@blogger.com (DotNetIdeas) — Sat, 28 Mar 2009 21:44:00 +0000

In Windows, there are two types of security mechanisms: Role based Security and Code Access Security. Role based security is easy to understand. Code Access Security(CAS) is to prevent “Bad” module from doing any damage. A module is “Bad” if it does not just do what it claims to do. For example, you run a module downloaded from internet to display a nice screen saver. However, although the module displays the screen saver, it also silently sends your local files to a remote location. In this case, the module does not just do what supposed to do.
How does CAS prevent “Bad” module from doing any damage? It is achieve by two mechanisms working together.
1. Configure CAS policy so the “Bad” module won’t have the CAS permission to do damage such as sending files to a remote location.
2. The code of sending file to a remote location must use CAS security Demand to demand the calling module to have the CAS permission. In case of sending files to a remote location. “WebRequest” CAS permission is demanded. Without the security demanding, configuring CAS policy is useless since CAS security enforcement typically starts with CAS permission demanding and then checks the security policy to see if the demanded permission is granted to the calling module.
While developing CAS strategy, in addition to configure CAS security policy, it is important to use the second mechanism so the code you wrote won’t be used by “Bad” module to cause any damage.

In SharePoint, it is a best practice to deploy your Dlls to the bin directory instead of GAC and configure minimum CAS permissions for the Dlls through CAS policy files. The tutorial will guide your through how to do it. The tutorial will use a couple of simple custom web parts, deploy them into the bin directory and use them in sharepoint content pages.

Lab 1: Deploy and use the first web part in SharePoint

Step 1: Develop DummyWebPart, build a Dll (Dummy.dll), copy dummy.dll to the SharePoint’s Bin directory

The source code of the first web part DummyWebpart is as the following

namespace Dummy

    [ToolboxData("<{0}:DummyWebPart runat=server></{0}:DummyWebPart>")]

    public class DummyWebPart : WebPart

        protected override void RenderContents(HtmlTextWriter output)

            output.Write("Hello World");

DummyWepart writes “Hello World”. That is it!

Step 2: Do not forget adding the following SafeControl entry to your web.config since we are using DummyWebPart in a Customized Content Page. It is important to know “SafeControl” has nothing to do with Code Access Security. It is something used by SharePoint Page Parser to forbid unregistered WebControl in a customized content page!

<SafeControls>

     ......

     <SafeControl Assembly="Dummy" Namespace="Dummy" TypeName="*" Safe="True" />

     ......

</SafeControls>

Step 3: Create a SharePoint Content Page Dummy.aspx to host the DummyWebPart. The source code of Dummy.aspx is as the following

<%@ Page Language="C#" %>

<%@ Register assembly="Dummy" namespace="Dummy" tagprefix="Dummy" %>

<html dir="ltr">

<body>

<form id="form1" runat="server">

<Dummy:DummyWebPart ID="DummyWebPart1" runat="server"/>

</form>

</body>

</html>

Now, open Dummy.aspx in the SharePoint site in a browser. It just works without any trouble

Lab 2: Deploy and use the second web part,DummySPWebPart, in SharePoint, which will cause Code Access Security Exception.

Step 1: Develop DummySPWebPart, build a Dll (SPDummy.dll), copy the SPDummy.dll to Bin directory

The source code of the second web part DummySPWepart is as the following

namespace SPDummy

    [ToolboxData("<{0}:DummySPWebPart runat=server></{0}:DummySPWebPart>")]

    public class DummySPWebPart : WebPart

        protected override void RenderContents(HtmlTextWriter output)

            output.Write(string.Format("root web title is {0}",SPContext.Current.Site.RootWeb.Title));

DummySPWepart writes the Title of the SharePoint root web site. It invokes SPContent.Current.Site.RootWeb.Title in order to get the Tile.

Step 2: Do not forget adding the following SafeControl entry to your web.config.

<SafeControls>

     ......

     <SafeControl Assembly="SPDummy" Namespace="SpDummy" TypeName="*" Safe="True" />

     ......

</SafeControls>

Step 3: Create a SharePoint Content Page SPDummy.aspx to host the DummySPWebPart. The source code of SPDummy.aspx is as the following

<%@ Page Language="C#" %>

<%@ Register assembly="SPDummy" namespace="SPDummy" tagprefix="SPDummy" %>

<html dir="ltr">

<body>

<form id="form1" runat="server">

<SPDummy:DummySPWebPart runat="server"/>

</form>

</body>

</html>

Now, open SPDummy.aspx in the SharePoint site in a browser. You will get the following:

The exception thrown is caused by invoking SPContext.Current.Site.RootWeb.Title, which requests for the CAS permission of type 'Microsoft.SharePoint.Security.SharePointPermission”. However, the current security policy does not grant the SPDummy.dll the CAS permission. In Lab 3, we will grant the CAS “SharePointPermission” to SPDummy.dll by editing CAS security policy.

Lab 3: Step by step guide on editing CAS

Step 1: Create a custom policy file wss_custom.config by copying the out-of-box policy file
a. Open directory “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG”. The directory contains the out-of-box policy files defining Wss_Medium and Wss_Minimal trust levels of SharePoint.
b. Make a copy wss_minimaltrust.config in the same directory and rename it to wss_custom.config.

Step 2: Refer to the “wss_custom.config” policy file from the web.config
a. Add a new trustLevel entry to the web.config. The trustLevel points to the new policy file wss_custom.config your created in step 1.

<securityPolicy>

      ......

      <trustLevel name="WSS_Custom" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_custom.config" />

</securityPolicy>

b. Change <trust level="WSS_Minimal" originUrl="" /> to <trust level="WSS_Custom" originUrl="" />

<trust level="WSS_Custom" originUrl="" />

After the first two steps, your sharepoint web application starts to use the custom poplicy file, wss_custom.config. Rememeber the “wss_custom.config” is just a copy of the out-of-box “wss_minimaltrust.config”. Now, we need to modify the file.

Step 3: Modify the “wss_custom.config” policy file so the Dlls in bin directory of the sharepoint web application have CAS SharepointPermission. You just need to add one IPermission element to an existing permissionset element as the follows:

<PermissionSet  class="NamedPermissionSet"  version="1" Name="SPRestricted">

<!-- add the following element -->

<IPermission

 class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

 version="1"

 ObjectModel="True"

/>

<!-- end of the element -->

</PermissionSet>

Save your change and open SPDummy.aspx. Now, it works without any exception!

How did I figure out to add the SharePointPermission to the SPRestricted permissionset? First, the exception message already tells you that we need to add SharePointPermission. So, you need to add IPermission element with SharePointPermission as its class.You can just use Version=”1”. The real catch is how to figure out adding ObjectModel=”true”. Go to http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.security.sharepointpermission_properties.aspx. You notice the SharePointPermission is a .NET class with three public properties. ObjectModel is one of them. What I did was to try each property and assign them to true. After a few tries, ObjectModel=”True” is the only one that really matters. There is no silver bullet here.
You should also ask why I choose to add it to SPRestricted PermissionSet. This requires a basic understanding of the structure of the CAS Policy file. Do a search on “SPRestricted” in the WSS_custom.config file. You will find the following element:

<CodeGroup class="UnionCodeGroup"  version="1" PermissionSetName="SPRestricted">

 <IMembershipCondition

    class="UrlMembershipCondition"

    version="1"

    Url="$AppDirUrl$/*"

/>

</CodeGroup>

This is the code group that dictates the CAS permission for all the Dlls under "$AppDirUrl$ directory, which includes the bin directory. This code group uses “SPRestricted” permission set. That is why to add the IPermission element to the “SPRestricted” permissionset.

NOTE, the tutorial explains the CAS security in SharePoint. In real world, you should use Windows SharePoint Packaging (WSP) to deploy the changes to CAS policy. This tutorial tells you what happens behind the scene. I will write another blog regarding the deployment in near future.

Develop Security Trimmed navigation Menu for SharePoint

noreply@blogger.com (DotNetIdeas) — Thu, 26 Feb 2009 14:42:00 +0000

In my previous article, I explained developing navigation menu in SharePoint using XML file and dataformwebpart. In this log, I will explain how to generate security trimmed navigation menu. To make things even more complex, there are two types of trimming:

1. Still show the menu item in the navigation, but while users click the menu, a message box should pop up and say "You are not authorized to view the page"

2. Will not show the menu item at all.

The solution is to add another SPDataSource to the DataFormWebPart in addition to the XML data source used to retrieve the XML file. (Notice, you are using AggregateSource here) The new datasource will perform a "CrossList" query to all the Pages libraries in the sitecollection. If the current log-in user does not have permission to view a page, the new datasource should not return any record for the page. So, in XSLT code, we just need to perform a filter not to generate menu item for those pages in XML datasource but not returned from the new datasource.

However, we have not solved the problem completely because, for some trimmed pages, we still need to generate menu item and hook up the java script code to display the pop up message box. The solution is to introduce a new attribute to the nodes in the XML file. For example, we can add a boolean attribute "IsGeneratingMessageIfNoPermmission" . The XSLT code will handle the property accordingly.

Once again, it demonstrates using "XML file + DataFormWebpart" to generate navigation menu for sharepoint is a very extensible approach, which fully takes advantage of the power of XSLT and dataformwebprt.

Why use SharePoint Content Pages instead of Simple ASP.NET pages for transactional page? (The elegant solution for implementing SharePoint user controls.)

noreply@blogger.com (DotNetIdeas) — Wed, 04 Feb 2009 15:37:00 +0000

A Page is transactional when the page needs to perform certain actions that require Server Side coding. If you want to implement the page in SharePoint and so End user can change the style of the Page through SharePoint designer, you have to implement the Server Side code in a Custom code behind Page class. You can place all the UI components in the SharePoint page or Page Layout in case of a publishing page. The code behind custom Page class will handle the server side logic. This approach will allow Designers to change the look/feel of the page through SharePoint designer while leaving the server side logic to developer. Allowing Designers to customize without any code change is the advantage to use SharePoint here.

The problem with this approach is that the Server Side logic is tied up with the page and so is not so reusable. What presented here is to use “Template” user controls/Custom controls to achieve the same functionality in a more reusable fashion. Basically, the all the UI components will be inside the “Template” properties of the User/Custom Controls. Therefore, they can be placed inside the SharePoint Page and End users can customize the templates through SharePoint designer.

It is not a new idea. It is exactly what ASP.Net “template” is designed for. It allows customized UI tied up to the same Server Side Logic. A good example is ASP.NET 2.0 login control, in which you can customize the layout of all the UI components while using for the same server side logic. The same idea applies perfectly in the context of SharePoint. SharePoint allows Users to customize the UI components through SharePoint designer while allowing certain degree of Server Side Activities. So, while writing User Controls for SharePoint projects, think about exposing “Template” properties and make them customizable through SharePoint Designer.

It is not so difficult to write a “template” controls. Please follow the link to learn how to add templates to a ASP.NET user controls http://weblogs.asp.net/scottgu/archive/2006/06/04/Supporting-Templates-with-ASP.NET-User-Controls.aspx

Integrate SharePoint Security with Line of Business (LOB) application

noreply@blogger.com (DotNetIdeas) — Wed, 28 Jan 2009 22:59:00 +0000

We have a legacy line of business web application. The application provides working platforms for various subscribers. We want to migrate the application to use SharePoint as its front-end and so to leverage SharePoint's site provisioning capability as well as other cool features such as customizable web part pages, survey/task list and so on.

As to security, the LOB has its own set of permissions, groups and users. All of them are stored in its custom database tables. SharePoint has its own concept of users, groups, permissions and permission levels. How to implement a security architecture to cover both of them? Before answering this question, we need to choose where to store all the LOB data. Should we store all of them in sharepoint lists/libraries? It is an easy decision because the LOB has a too complex relational database for SharePoint to handle. The CAML query and Search provided by SharePoint are more like a Meta data search facility, which are not very helpful for handling relational/transactional data. So, most of the transactional relational data should stay in the LOB database and the sharepoint security won't apply to those data. Therefore, we need to implement a security architecture to cover both sharepoint data and the LOB data. Essentially, the security architecture should allow to assign both sharepoint and custom permission to users. For example, We can say "User ABC" can "view web part" pages and "make purchase of product XYZ".

The overall architecture is as the following:

1: Use out-of-box ASP.NET form authentication's SQL membership and SQL role provider. (Notice, we choose not to create a custom security providers.)

2: Create database tables in the LOB database to map a ASP.NET form user to LOB permissions such as make "purchase of product XYZ".

3: Create custom sharepoint admin pages for managing ASP.NET users, roles and assigning both sharepoint permission levels and LOB permissions to them.

The code logic behind those admin pages is straightforward. For example, The logic flow to create an user group and assign permissions to the group is as the following:

1: Use ASP.NET role API to create an ASP.NET role. (ASP.NET role is basically a user group)

2: Use SharePoint object model API to map the ASP.NET role to a SharePoint User.

3: Assign the corresponding Permission Levels to the SharePoint User.

4: To assign LOB permissions to the ASP.NET role, use LINQ to SQL (the latest ASP.NET 3.5 dataaccess API) to update the LOB tables

The whole process is straightforward and simple as long as you have a clear understanding on ASP.NET form security and SharePoint Security.

Some of the key points that help to come to the design are:

1: ASP.NET role provider is essentially "Membership Group". It is not responsible for mapping a "Membership Group" to "Security Permissions". A Membership Group determines who are in the group. It does not know what permissions the group has.

2: SharePoint Permission Levels are "Permission Group".

3: LOB have its own permissions.

4: The security architecture is to Reuse the "Membership Group" feature from ASP.NET role provider and use custom coding to map the ASP.NET role to SharePoint permission levels and LOB permissions.

It is often confusing about different terminologies such as group, role, permission level and so on. Try to translate those terminologies into a common language such as Permission, Permission Group and Membership Group. Distinguishing Permission Group from Membership Group and understanding the process to assign Permissions/Permission Groups to Membership Group are very important.

How to author Movie/Flash in SharePoint Publishing Site with minimum coding

noreply@blogger.com (DotNetIdeas) — Fri, 23 Jan 2009 19:35:00 +0000

Displaying Movie content is a common requirement in a Publishing Site. The typical behavior is as the following:

In Authoring/Edit Mode, content authors can choose which movies to display.

In Display Mode, end users will see the movie or just a link to the movie, clicking the link will pop up a dialog to show the movie.

The behavior is very similar to the out of box “RichLinkField” (Publishing Hyperlink). Actually, they have the exact same Edit Mode behavior. The only difference is that “Publishing Hyperlink” will render Anchor link in display Mode whereas Displaying Movie needs to render different HTML segment depending on how to play movie.

So, instead of building a custom SharePoint Field Type, we just need to build a custom SharePoint field control, which inherits from out-of-box “RichLinkField” class and overrides “RenderFieldForDisplay” method. The field control will present the same Edit Mode behavior as Publishing Hyperlink while in Display model; it renders the HTML/JavaScript for displaying Movie.

The approach is very simple and effective. It demonstrates the power of SharePoint’s extensibility.

How to implement complex Menus/Breadcrumbs/Navigation structure in a SharePoint environment?

noreply@blogger.com (DotNetIdeas) — Fri, 23 Jan 2009 14:49:00 +0000

It is natural to try to use out-of-box components such as navigation providers, site map data sources and menu controls. However, it is very often true for a complex content management SharePoint project that the out-of-box features are not enough. There are typically two reasons

1. The logical structure is different from what out-of-box could envisioned or

2. The custom CSS/JSScript involved is just too complex to be expressed in configuration parameter on out-of-box menu controls.

Notice, typically SharePoint developers do not have control on those factors since, for a complex project, web designs typically come from third party companies specialized in web design.

The solution, which proves to be successfully in several projects, is to use a XML file to define the site structure and use DataFormWebPart (Data View Web Part) to generate the HTML/CSS/Java script for the menus and even breadcrumb.

In the XML file (Site Map), each node may have an attribute for the URL to the page and some other Meta data attributes to help generate menus. For example, if a node should be only visible for certain groups of user, you can add an attribute to the node to specify the groups. Adding Meta data in the XML file is an extensible approach since you can add a new attribute easily. It is also a maintainable approach due to its centralized nature. Adding Meta data in publishing page content type is an alternative. However, it is decentralized and typically difficult to maintain.

With the XML file defining the complex logic structure, all you need to do is to convert it to HTML/CSS/JavaScript. Then, both problems mentioned earlier are solved. XSLT is the perfect candidate for this convertion and therefore DataFormWebPart can be used. In a publishing web site, you can simply put the XML file in style library and use DataFormWebPart to get its content. To this end, a solid understanding of DataFormWebPart is a necessary. This is not a DataFormWebPart tutorial. Here are a few concepts you can use to quiz how well you understand DataViewWebPart.

1. How to define a SPDataSource to query data from a list by Name.

2. SPDataSource supports two modes of Query. Which are they?

3. How to define an aggregate data source.

4. How to use PostBack parameter binding.

5. How to use a control parameter binding.

6. How to reuse XSLT in two fashions, utility and framework.

If answers are “yes” to all of them and you also have good SharePoint designer experience, you are definitely ready to consider DataFromWebPart as an important part of your SharePoint site architecture.

Notice, item 6, “how to reuse XSLT in two fashions”, is crucial if your XSLT code exceeds a few hundred lines. With DataFormWebPart, you can use XSLT “import” to reuse the templates/variables from other XSLT files. (I have seen some blog saying it is not possible, which is not correct.). You can achieve “FrameWork” like reuse based on the following feature of XSLT:

A template will override the ones with the same name but defined before it. For example, you can have a XSLT file “FA” defined a template “TA”, which invokes template “TB”. You can provide a default implementation for “TB” in “FA”. Another XSLT file “FB” can import “FA” and provide a different implementation of “TB”.

“Framework” style reuse is very powerful. It is just like the “virtual” function in object oriented programming.