Connecting Web Parts in SharePoint Portal Server 2003, Part 2

Connecting Web Part Exercise

I am using an ICellProvider Web Part to display the functionality of a connectable Web Part. The Cell Provider Web Part contains a textbox where end users can enter a value and a button. When the Cell Provider Web Part is connected to another Web Part, the value entered to the textbox will be passed to the consumer Web Part. Article two in this series will focus on how to create Cell Provider Web Parts.

The end users select the dropdown arrow at right hand corner of the Web Part when they are ready to connect the Web Part. End users should make sure that the page is in design view. The information about the Web Part will display as shown below, explaining the functionality of the Web Part.

The developer has the option to enter a meaningful description about the Web Part when developing it.

It will display a list of Web Parts that are compatible to connect to the Web Part as displayed below.

Currently only one Web Part is indicated compatible with the Provider Web Part. Simply clicking the “Cell Consumer Web Part” will connect the Cell Provider Web Part with “Cell Consumer Web Part”.

A right sign will indicate which Web Part is connected to what as displayed below.

Article three in this series will focus on how to create ICellConsumer Web Parts.

The connection between and ICellProvider and ICellConsumer Web Part.

The value entered in the textbox at Cell Provider Web Part will get consumed by Cell Consumer Web Part.

Disconnecting the Web Parts

To remove the connection between two Web Parts, navigate to design view of the Web page and click the connected Web Part title. (The connected Web Part title will display with a right mark in front.). A message will display to confirm your action as displayed below:

Removing connection between Web Parts.

Web Services and Connectable Web Parts

Web services are mainly developed to provide specific data to a consumer. The developer has full control over exposing the Web service. The connectable Web Parts provide the option to the end user. The connectable Web Part can stand alone as individual Web Parts providing their dedicated information and then connect them together to provide filtering of information.

For example, there can be an employee list Web Part and employee details Web Part. Both of the Web Parts can stand alone providing information. If the end user wants to display the details of a selected employee, the end user has the option to connect the employee list Web Part to the employee detail Web Part. In this way, when the end user selects an employee from the employee list, the selected employee details will display in the details Web Part.

If you develop a Web service to cater to the above scenario, the developer has full control of the end result. The functionality provided by the Web service is not visible to the end user and the end user won’t have knowledge or control to reuse the Web service if they need to in the future. At the end of the day it’s reliant on whether you want to create a dedicated Web service or individual Web Parts that can stand alone and work together if needed.

The biggest benefit Web Parts have over a Web service is the reusability and the option for the end user to have control of their environment. This is a very important aspect in a portal architecture where end users have control over what they see. Portals are mainly developed so that end users can gather information relevant to them and centralize it. End users having more control over their environment is better than depending on a developer in a portal environment.

Conclusion

The connectable Web Parts are similar to normal Web Parts. The only difference is they are inheriting from a connection interface class that provides capability to communicate with other Web Parts at run time, so they can act as service if needed. Articles two and three of this series will show how to develop connectable Web Parts using the ICellProvider and ICellConsumer interfaces.

Connecting Web Parts in SharePoint Portal Server 2003, Part 1

Microsoft’s SharePoint Portal Server lets different developers and organisations develop Web Parts that can communicate with each other. A Web Part is a modular unit of information that works with Windows SharePoint Services Web sites only.

Web Parts contain Web-based content and are the building block of a Web Part Page. You can also create connections between Web Parts so that when you perform an action in one Web Part, it changes the contents of another Web Part.

The SharePoint architecture supports standard Connection Interfaces for passing information among Web Parts at runtime. The connectable Web Part will act as a provider Web Part by providing information to another Web Part or as a consumer Web Part by consuming information from a provider Web Part. Two Web Parts supported by a connection interface can be connected by an end user with either Microsoft Office Front Page or an Internet browser.

Connection Interface Details

There are few a different connection interfaces that provide different behaviors. The difference is mainly found in the amount of information that can be passed from one to another. For example, one interface can support providing a single value to a consumer Web Part. There are other interfaces that support more than a single value.

The connectable Web Part raises an interface event that executes an action in Web Parts connected to it. These connection interfaces act as pairs by either being a provider or consumer Web Part. An event from the provider will trigger an action in the consumer Web Part, and an event from the consumer Web Part will trigger an action in the provider Web Part. The following are some of the connection interface pairs and their functionality.

Connection Interface Pairs and Their Functionality
Connection Interface Pair Functionality
ICellProvider, ICellConsumer Provide or consume a single value from one Web Part to another.
IRowProvider, IRowConsumer Provide or consume a single or multiple rows of values from one Web Part to another.
IListProvider, IListConsumer Provide or consume an entire list from one Web Part to another.
IFilterProvider, IFilterConsumer Provide or consume a filter value.

There are more connection interfaces available from the SharePoint architecture. However, I am mainly looking at interfaces connected using an Internet browser. There are a few more interfaces that are supported by Microsoft Front Page.

Web Parts can be connected only if they are compatible with each other. If Web Parts are not compatible, the Connection menu item in the Web Part will be disabled, and a tool tip will display the reason why it is disabled.

Compatibility Rules

The Web Part won’t be able to connect to itself either directly or through a chain of connections. There are a few compatibility rules that SharePoint architecture follows when determining whether the Web Parts are compatible.

  • Are the Web Parts connecting as opposite pairs? For example, only ICellProvider interface can be connect with ICellConsumer interface.
  • Is the Web Part connecting through a Transformer? The Web Part architecture supports connecting dissimilar Web Parts with each other through transformers. For example, the IRowProvider Web Part can connect with either the IRowConsumer or the ICellConsumer Web Part. When it is connected to an ICellConsumer Web Part, the transformer determines which field will be consumed from the provider Web Part. The following are some of the transformers supported by connecting through a browser:IRowProvider to ICellConsumer
    IRowProvider to IFilterConsumer

The following are some of the interfaces that support the cross page connections. This means Web Parts in two different pages can communicate with each other.

Interfaces Supporting Cross Page Connection
Source page Interface Target page Interface
IRowProvider IFilterConsumer
IFilterProvider IFilterConsumer

Web Parts can run on the client side, server side, or both. The connectable Web Part only can connect with other connectable Web Parts in the same location. This means both Web Parts should run either client side or server side. A client side Web Part won’t be able to connect to a server side Web Part and vice versa.

When the developer creates the Web Part, he can determine the number of connections supported by the Web Part. This is done when the interface is registered in the code. The connection number can be either one or unlimited.

Connect Web Parts Through an Internet Browser

According to the SharePoint Portal Server 2003 Client section on Microsoft’s SharePoint Portal Server 2003 System Requirements page, “To use the SharePoint Portal Server 2003 client, you need:

Portal access

  • Microsoft Internet Explorer 5.01, plus the latest service pack
  • Internet Explorer 5.5, plus the latest service pack
  • Internet Explorer 6, plus the latest service pack
  • Internet Explorer 5.2 for Mac OS X, plus the latest service pack
  • Netscape Navigator 6.2 or later
  • Netscape Navigator 6.2 for Mac
  • Netscape Navigator 6.2 for UNIX

Portal management

  • Internet Explorer 5.5, plus the latest service pack
  • Internet Explorer 6, plus the latest service pack

The Web page that contains the Web Parts should be in design view to support the connection functionality; otherwise, the connecting Web Part option won’t be available to the end user. To access the design view of a SharePoint Web page, navigate to the top right hand corner and select Modify My Page or Modify Shared Page depending on whether the end user is using personal or shared view. Then select Design this page option from the dropdown menu as displayed below.

A right mark will indicate whether the page is in design view as displayed below.

There are more options available in a Web Part menu when its holding page is in design view. The Web Parts “Connections” option only is available when the Web Part is displayed in design view.

Friday, July 4, 2008

Creating a Basic Web Part

This walkthrough provides the steps for creating a basic custom Web Part that you can add to your Web Part page. It is a simple HelloWorld Web Part demonstrating how to create a Web Part that derives from the ASP.NET 2.0 WebPart class for use in a SharePoint site.

NoteNote:
For more information about ASP.NET Web Parts, see the following ASP.NET 2.0 documentation: ASP.NET Web Parts Quick Start and ASP.NET Web Parts Pages.
Windows SharePoint Services 3.0

Visual Studio 2005

Step 1: Create an ASP.NET Web Part assembly

To create a simple Web Part, you start by developing an ASP.NET Web Part assembly. To start, you can create a class library project with a class that derives from the System.Web.UI.WebControls.WebParts.WebPart base class.

Create an ASP.NET Web Part Assembly

  1. Start Visual Studio 2005.
  2. Start a new C# class library project.
  3. Type HelloWorldWebPart as the project name.
  4. Add a reference to System.Web.
  5. In your .cs file, copy and paste in the following code:
    using System;
    using System.Text;
    using System.Web.UI.WebControls.WebParts;
    namespace MyWebPartLibrary
    
    {
     public class HelloWorldWebPart : WebPart
       {
        protected override void Render(System.Web.UI.HtmlTextWriter writer)
         {
            writer.Write("Hello, World!");
         }
       }
    }
  6. Compile the solution. Now you have an assembly that contains your HelloWorldWebPart Web Part.

Step 2: Place your assembly in the bin or global assembly cache

Within a SharePoint site, you can deploy a Web Part assembly to one of two locations:

  • bin directory: The bin directory is a folder stored in your Web application root directory. For more information, see How to: Find the Web Application Root.
    NoteNote:
    If a bin directory does not exist you must add one. Web Parts cannot be stored in the _app_bin directory.
  • global assembly cache: The global assembly cache enables you to share assemblies across numerous applications. The global assembly cache is automatically installed with the .NET runtime. Components are typically stored in C:\WINNT\Assembly.

Each location has advantages and disadvantages, as described in the following table.

Deployment Location Advantages Disadvantages
bin directory A partial trust location. By default, code that runs from this directory has a low level of code access security (CAS) permissions. Because administrators must explicitly raise permissions granted to a Web Part so it can function properly, they can prefer that assemblies run in the bin directory with a known set of required CAS permissions.

A bin directory is specific to a Web application. This makes it possible to isolate code to a particular Web application.

If you want your Web Part to run everywhere, you would need to deploy your bin assembly.
global assembly cache A global location where signed assemblies can be deployed. Assemblies run with full trust by default. They are globally installed, so they will work in any Web application. Generally no CAS restrictions on code installed to the global assembly cache; therefore, you lose the defense-in-depth security benefit.

For the purposes of this sample, we are placing the assembly in the bin directory.

Step 3: (Optional) If using the bin directory, set special security attributes

By default, code access security permissions for the bin directory are low; only pure execution is allowed. Although the sample in this walkthrough can run with the minimal trust level, in most cases you need to elevate these permissions to make your assembly run correctly, for example, if your Web Part requires access to the SharePoint object model.

There are two ways to elevate permissions:

  • (Recommended) Create a new trust policy file, and point your web.config file at the new file. This option is more complicated but it gives you a precise attribution of permissions for your Web Parts.

    For more information about trust policy files, see Microsoft Windows SharePoint Services and Code Access Security.

  • Raise the net trust level of the bin directory. In the web.config file in the Web application root, there is a tag called with a default attribute of level="WSS_Minimal". You can change this level to WSS_Medium. While this option is simpler, it grants arbitrary new permissions you might not need and is less secure than creating a new trust policy file.

To raise the trust level of the bin directory

  1. Locate the web.config file in your application root and open it for editing.
  2. Locate the trust level tag, . Change the trust level to WSS_Medium.

Step 4: Add your Web Part to the SafeControls List

A fundamental assumption of the Windows SharePoint Services technology is that untrusted users can upload and create ASPX pages within the system on which Windows SharePoint Services is running. To prevent these users from arbitrarily adding server-side code within ASPX pages, Windows SharePoint Services provides a SafeControls list, which is a list of approved controls that they can use.

The SafeControls list is a list of controls and Web Parts specific to your SharePoint site that you have designated as safe for invocation on any ASPX page within your site. This list is contained in the web.config file in your Web application root.

To add your Web Part to the Safe Controls list

  1. Open the web.config file in the application root.
  2. Add a safe control entry for your custom assembly to the web.config file as follows:

    [xml]

Step 5: Create a .webpart file for your Web Part

Every Web Part should have a .webpart file, which is an XML file that describes the Web Part. The .webpart file also makes your Web Part appear in the Web Part gallery. This procedure describes the easiest way to create a .webpart file.

To Create a .webpart file for your Web Part

  1. After you have deployed your Web Part and registered it in the Safe Control list, navigate to http://myserver/_layouts/newdwp.aspx, where myserver is the name of the server on which your SharePoint site is deployed.
  2. Select the check box next to MyWebPartLibrary.HelloWorldWebPart.
  3. Click Populate Gallery and the Web Part is added to the Team Site Gallery.
    NoteNote:
    To create a .webpart file for your Web Part, you can select Edit for the Web Part in the Web Part Gallery, and then click Export. You are prompted to provide a location in which to put the .webpart file.

Step 6: Add your Web Part to a Page

In this step, you import the Web Part to a page in any SharePoint site. The following procedure explains the steps for adding the Web Part to a page.

To add and test your Web Part

  1. Navigate to the Web Part page on your SharePoint site where you want to add the Web Part.
  2. In the Web Part page, click Site Actions, and select Edit Page.
  3. In the Web Part zone where you want to add the HelloWorldWebPart, click Add a Web Part.
  4. At the bottom of the Add Web Parts dialog box, click Advanced Web Part gallery and options.
  5. Open the Team Site Gallery and drag the HelloWorldWebPart onto the page. The Web Part displays the SharePoint look and feel.

Thursday, July 3, 2008

Presentation on SharePoint WebParts to Bellingham .NPresentation on SharePoint WebParts to Bellingham .NET Users Group ET Users Group

Andrew Robinson, the president of the Bellingham .NET Users Group, invited me to give a talk to his group. I will be giving them a talk on “WebParts for SharePoint 2007” on Wednesday January 8, 2007 starting at 6:00 PM. Bellingham is the most visited city accross the border for British Columbians and I look forward to forging closer ties between .netBC and the Bellingham .NET Users Groups.
Here is the extract of my talk:
WebParts for SharePoint 2007
WebParts provide the fundamental building blocks for creating custom applications for SharePoint. This session will show you how to efficiently and quickly use your ASP.NET 2.0 and C# skills to develop WebParts for deployment into SharePoint 2007. Most of the development, testing and debugging will be done in Visual Studio .NET 2007. We shall then deploy the WebPart as a feature into Windows SharePoint Services 3.0 (WSS 3.0). We will also look at WebPart communication and modifying WebPart verb menus.
Wednesday January 9, 2008
The files that make up my presentation can be downloaded from here.
Thursday January 10, 2008
I had an enjoyable time at Bellingham. There were 13 people in attendance. Pizza was great and I was glad that they serve water instead of the dreaded pop.

FBA pointing to Active Directory

SharePoint and ExCM can use any Membership provider for operations like authentication, add users, reset passwords. The .NET framework provides two membership providers out-of-the-box (ActiveDirectoryMembershipProvider, SQLMembershipProvider). You can use the ActiveDirectoryMembership provider to connect to AD or AD LDS (ADAM). MOSS 2007 comes with an an additional provider named LdapMembershipProvider which can be used to connect to AD via LDAP or other LDAP sources. However, not every provider supports the same operations and the AD/LDAP providers can be more difficult to implement.

When selecting a provider you also have to think about Role and Profile providers. SQL supports all three provider types. AD supports only membership and the LDAP provider supports membership and roles. This is the reason why most customer choose to implement SQL membership, because it is fully functional and scales well. Please take a look at some of the links below for more information…

General

(Authentication Samples)
http://technet2.microsoft.com/windowsserver/WSS/en/library/91035419-980e-4230-b3ae-67253b94af4a1033.mspx?mfr=true

(Plan authentication settings)
http://technet.microsoft.com/en-us/library/cc288081.aspx

(Forms based authentication in MOSS)
http://blogs.msdn.com/harsh/rss_tag_FBA.xml

(How to use Membership in ASP.NET 2.0)
http://msdn2.microsoft.com/en-us/library/ms998347.aspx

LdapMembershipProvider

(LDAP Membership Provider Class)
http://msdn2.microsoft.com/en-us/library/microsoft.office.server.security.ldapmembershipprovider.aspx

(Configure forms-based authentication against an LDAP data store in Office Project Server 2007)
http://technet.microsoft.com/en-us/library/cc197721.aspx

(Moss LDAP Membership Provider)
http://blog.hametbenoit.info/Lists/Categories/Category.aspx?Name=Security

(Using LdapMembershipProvider in SharePoint, and get it to work!)
http://www.sharepointblogs.com/rhulsman/archive/2006/12/12/using-ldapmembershipprovider-in-sharepoint-and-get-it-to-work.aspx

ActiveDirectoryMembershipProvider

(Active Directory Membership Provider Class)
http://msdn2.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx

Alternate Access Mappings

(Plan alternate access mappings)
http://technet2.microsoft.com/windowsserver/WSS/en/library/c8ccffce-5162-46af-a3ef-1d7914e8efee1033.mspx?mfr=true

(Configure alternate access mapping)
http://technet2.microsoft.com/windowsserver/WSS/en/library/8642f748-f169-4799-8fe9-8140fbb23fbf1033.mspx?mfr=true

Wednesday, July 2, 2008

Office SharePoint Server 2007 – Forms Based Authentication (FBA) w/MySites Walk-through – Part 2

As promised, here is part 2 of my series on hooking up Forms based authentication on a SharePoint 2007 site AND integrating your web application with MySites and the Personalization features of Office SharePoint Server 2007.

I am going to assume that you have read and gone through all of the steps in part 1 of the series. The steps below ARE dependent on part 1 and I will be making some references to it. If you have not gone through part 1, I encourage you to read this entire post before trying to implement the solution. There are quite a few caveats and very UNINTUITIVE steps. Since none of this is documented (to my knowledge), I have to say that since it is undocumented, it may be unsupported as well. What I can say for certain, that in my 2 or 3 support calls to Microsoft regarding this issue, I had given up on them helping me. Essentially I was told on more than one occasion that “it’s not supposed to work” or “it does not work”. Of course after those answers, I had to prove to myself that either it does work or support was right. They do after all claim that this is “pluggable” authentication, and other than the obvious features, like Office integration, or SharePoint Designer integration, I expected all of the functionality to work. The following is the fruit of my labor. As a side note, this effort, although it may seem simple after you go thru the steps, took me about 5 weeks of nights and weekends trying to get the sequence of steps and the steps themselves defined.

One major disappointing caveat is MySite search. Search works fine against the FBA site to which we have a “mirror” intranet version, like we do in our example, but unfortunately we do not have a Windows authentication version of each and every MySite. I guess we could, technically, but really, that’s not going to happen. I have heard however, through a very reliable source that Microsoft is working VERY VERY hard on getting the SharePoint search crawler to be able to penetrate forms based authentication sites and just maybe, might have a solution in Q2. I am optimistic about this and can’t wait, then we really have a fully searchable FBA solution.

So here goes…

Assumptions

Like any good assumer, I am going to list all of my assumptions here. If you think that anything is missing, please do let me know and I will update this list.

  • You have created and configured a Shared Services Provider (SSP) and can link to its setting page using either of the following two methods.
    • Click on the Share Services Provider’s link in the left navigation in Central Administration.

    • Click on the Create or configure this farm’s shared services link in the Office SharePoint Server Shared Services section of the Application Management tab in Central Administration, then select Edit Properties from the dropdown menu that appears when you hover over its name.

  • The SSP Administrative Site URL and the MySite Location URL are each on their own web applications.

    It is possible and sometimes desirable for some to locate their MySite site collections within the same Web Application of the site to which they are associated. What I mean by this is that there are two very different ways in which to setup MySites and they are as follows. Let’s pretend for the sake of conversation, that our site is http://www.microsoft.com.

    Method #1 – The site http://www.microsoft.com is its own Web Application. In turn, http://www.microsoft.com/mysite is where the MySites site collection is located. The main benefit to this design is that since we are using FBA as our authentication method, the same cookie will work for both sites and we will not have to log into our MySite independently of logging into the main site. The main drawback is that MySites will now be created in the same content database(s) that the http://www.microsoft.com Web Application is using. This may be an issue when it comes to scaling and capacity planning. Chris Johnson has outlined the steps needed to produce this scenario here.

    Method #2 – The site http://www.microsoft.com is its own Web Application. In turn, my.microsoft.com is where your MySites site collection is located. The main benefit to this is that MySites are stored in a separate Web Application and can be managed independently. The main drawback is that since we are using FBA as out authentication method, we will have to log into our MySite separately, the cookie will not be shared.

    Microsoft’s best practice dictates that you use Method #2, so that is what I have done in my walkthrough.

  • As indicated above, for the purpose of this post, my SSP Administrative Site URL is http://ossdev:23456/ssp/admin.
  • As indicated above, for the purpose of this post, my MySite Location URL is http://ossdev:23457.
  • You will NOT access the URL in the previous bullet until instructed to do so. This has the potential to create problems, so please resist the urge.
  • You will NOT click on the MySite link until instructed to do so. This also has the potential to create problems, so please resist the urge.

Update the Shared Service Provider Administrative Site’s web.config File

The web.config file of the Shared Service Provider needs to be updated with the same information you placed into the web.config of your FBA web application.

Determine File Path to web.config.

  1. Open Internet Information Services (IIS) Manager.
  2. Expand Web Sites and select the Shared Service Provider’s website, in my case, SharePoint_SSP_Default1 – 23456. Yours will most likely be different so be sure you select the right site.
  3. Right click on the above website and select Properties.
  4. Select the Home Directory tab.
  5. In the Local path textbox take note of the entire string. This is the folder on the file system that contains the web.config for the http://ossdev:23456/ssp/admin web application. We will be updating this file next.
  6. Open Windows Explorer and browse to the folder noted in step 5.
  7. Make a backup copy of the web.config file.

Add Connection String

  1. Add the following connection string snippet immediately above the tag. Be sure to replace the bolded text with the appropriate values from your environment.

    AspNetDbFBADemoConnectionString” connectionString=”Data Source=OSSDEV;Initial Catalog=AspNetDb_FBADemo;Integrated Security=True” />

Add Providers

  1. Add the following membership provider and role manager elements immediately inside the element. Again, be sure to replace the bolded text with the appropriate values from your environment.


    FBADemoMember”>

    AspNetDbFBADemoConnectionString”>
    enablePasswordRetrieval=”false”
    enablePasswordReset=”true”
    requiresQuestionAndAnswer=”false”
    applicationName=”/”
    requiresUniqueEmail=”false”
    passwordFormat=”Hashed”
    maxInvalidPasswordAttempts=”5″
    minRequiredPasswordLength=”1″
    minRequiredNonalphanumericCharacters=”0″
    passwordAttemptWindow=”10″
    passwordStrengthRegularExpression=””
    name=”FBADemoMember
    type=”System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a” />


    FBADemoRole”>

    AspNetDbFBADemoConnectionString”>
    applicationName=”/”
    name=”FBADemoRole
    type=”System.Web.Security.SqlRoleProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a” />

  2. Save and close the web.config file.
  3. Perform an IISReset and verify that you can still access the SSP.

Update the MySite Host Web Application’s web.config File.

The web.config file of the MySite Host Web Application needs to be updated with the same information you placed into the web.config of your FBA web application.

Determine File Path to web.config.

  1. Open Internet Information Services (IIS) Manager.
  2. Expand Web Sites and select the MySite Host website, in my case, SharePoint_MySite_Default1 – 23457. Yours will most likely be different so be sure you select the right site.
  3. Right click on the above website and select Properties.
  4. Select the Home Directory tab.
  5. In the Local path textbox take note of the entire string. This is the folder on the file system that contains the web.config for the http://ossdev:23457 web application. We will be updating this file next.
  6. Open Windows Explorer and browse to the folder noted in step 5.
  7. Make a backup copy of the web.config file.

Add Connection String

  1. Add the following connection string snippet immediately above the tag. Be sure to replace the bolded text with the appropriate values from your environment.

    AspNetDbFBADemoConnectionString” connectionString=”Data Source=OSSDEV;Initial Catalog=AspNetDb_FBADemo;Integrated Security=True” />

Add Providers

  1. Add the following membership provider and role manager elements immediately inside the element. Again, be sure to replace the bolded text with the appropriate values from your environment.


    FBADemoMember”>

    AspNetDbFBADemoConnectionString”>
    enablePasswordRetrieval=”false”
    enablePasswordReset=”true”
    requiresQuestionAndAnswer=”false”
    applicationName=”/”
    requiresUniqueEmail=”false”
    passwordFormat=”Hashed”
    maxInvalidPasswordAttempts=”5″
    minRequiredPasswordLength=”1″
    minRequiredNonalphanumericCharacters=”0″
    passwordAttemptWindow=”10″
    passwordStrengthRegularExpression=””
    name=”FBADemoMember
    type=”System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a” />


    FBADemoRole”>

    AspNetDbFBADemoConnectionString”>
    applicationName=”/”
    name=”FBADemoRole
    type=”System.Web.Security.SqlRoleProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a” />

  2. Save and close the web.config file.
  3. Perform an IISReset and close all your browser windows, but DO NOT try and access this URL yet.

Assign FBA Admin User Personalization services permissions.

Remember in part 1, we created a handful of FBA users. One of those users (spadmin) was created to be used as an administrator for our FBA site. We are going to re-use that user here to manage the SSP once we “flip” it to Forms Authentication. Yes, that’s right, we are going to switch the authentication method of our SSP Administration site to Forms! How else did you think it would wok with FBA users? Ideally, you should probably go and create another user for this, maybe sspadmin or something similar.

  1. Browser to your SSP Administration Site.
  2. Click on Personalization services permissions in the User Profile and My Sites section.

  3. Click on the Add Users/Groups link.

  4. Type spadmin into the Users/Groups textbox and click the Check Names button , watch SharePoint resolve the user, then check all of the permissions and click Save. This will ensure that when we make the switch to Forms Authentication on the SSP site, that our FBA admin user will actually be able to perform the operations listed here.

  5. Perform an IISReset and close all your browser windows.

Switch Authentication Providers for SSP and MySites

  1. Click on the Authentication providers link in the Application security section on the Application Management tab in Central Administration.

  2. Verify that the SSP Web Application is selected in the Web Application dropdown in the top right hand corner of the page.

  3. Click on Default.

  4. Select Forms as the Authentication Type, and enter the appropriate values for the Membership provider name and the Role manager name as they exist in this web application’s web.config, then click OK.

  5. Perform steps 1 to 4 again for the MySite Web Application.

Update Site Collection Administrator for SSP and MySites

We now need to update the Site Collection Administrators of the SSP and MySite host so we can go make some more changes.

  1. Click on the Site collection administrators link in the SharePoint Site Management section of the Application Management tab in the Central Administration.

  2. Switch the Site Collection dropdown to the SSP admin Site Collection. Remember, you may have to switch the Web Application to get the correct list of Site Collections (this is done in the popup). I know of some people who are not too fond of this user interface, myself included). Notice that since we switched the Authentication Type of our SSP to Forms, we will see a squiggly under the Windows account that was previously the Site Collection Administrator.

  3. Delete the squigglied name (is that a word?) and replace it with spadmin, the FBA admin user we discussed earlier. Click the Check Names button and watch SharePoint resolve the FBA admin user, then click OK.

  4. Repeat steps 1 to 3 for the MySite Host Site Collection.

Assign My Site Host Permissions to FBA Users

The following steps were the most unintuitive steps ever, in my opinion, and if anyone can tell me why it is required for FBA/MySite integration, but not for Windows/MySite integration I would love to know. That said, here are the steps.

  1. Browse to your SSP Administration site.
  2. You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
  3. Click on the My Site settings link in the User Profiles and My Sites section on the SSP Home page.

  4. Click on the My Site Host Permissions link in the loft navigation.

  5. You will be prompted with the standard out of the box FBA login form. Log in as spadmin. You will be directed to the People and Groups page.

  6. Click on the Site Permissions link in the left navigation.

  7. Click on Add Users under the New menu item.

  8. Add the 3 roles we created in part 1, Administrator, Manager and Employee. Ideally we would have created a role that holds all of the FBA users (maybe call it Everyone). Had we done that in part 1 (we did not and I apologize), we would only have had one role to add here and so long as we always assigned new users to the Everyone role we would never have to come to this page again. As it stands now, if we were to create another user and place them in a new role, they would not be able to create a MySite. I think you get my drift here. Give them Read permission directly and click OK.

    Actually, doing this doesn’t actually give users permission to create a MySite, but permission to use the MySite Host site should they already have the permission to create a MySite. The next section will grant users permission to create MySites.

  9. Close all your browser windows.

Grant Personalization Services Permissions

The next set of steps, as mentioned above is to grant our FBA users the appropriate permission to allow them to create MySites and use the personalization features of Office SharePoint Server 2007.

  1. Browse to your SSP Administration site.
  2. You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
  3. Click on the Personalization services permissions link in the User Profiles and My Sites section of the SSP Home page.

  4. Click on the Add Users/Groups link.

  5. Type Administrator;Manager;Employee into the Users/Groups textbox and click the Check Names button , watch SharePoint resolve the roles, check only the Create personal site and Use personal features permission, and click Save. This grants these roles the permission to create a MySite and to use the personalization features.

  6. Your screen should resemble the following screen shot.

  7. Perform an IISReset and close all your browser windows.

Assign Roles to Default Reader Site Group

Ideally, we don’t want users to have to assign other users Read permission just to view the public areas of their MySites. When using Windows authentication, the default is to allow all authenticated users to read other users MySites. Such a group does not exist when using FBA. Had we created some sort of Everyone role, as suggested earlier in this post, in part 1 of the series, we could have leveraged that role, however, since we did not, we will have the same scenario as before manifest itself should we decide to add a new role in the future, after making the following changes. So lesson learned #1 would be to create an Everyone role in your role manager and place all of your users in it.

  1. Browse to your SSP Administration site.
  2. You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
  3. Click on the My Site Settings link in the User Profiles and My Sites section on the SSP Home page.

  4. Scroll down to the Default Reader Site Group section and type or append Administrator; Manager; Employee into the textbox. You can leave NT AUTHORITY\authenticated users in the textbox or remove it, it does not matter at this point, then click OK.

  5. Close all your browser windows.

Test You Solution!

Remember, I made allot of assumptions at the beginning of this post. One of those assumptions was that you had completed part 1 of this series. Under the assumption that you have completed part 1, test your solution using these steps.

  1. Browse to http://fbaextranet.attis.org and first login as spadmin. You should see a My Site link in the top right hand corner of the page. DO NOT CLICK ON IT YET.
  2. Verify that the Employee role is in the pre-created Visitor SharePoint group and that the Manager role is in the pre-created Member SharePoint group (I have to assume you know how to do this!).
  3. As I mentioned earlier, since we set our My Site Host site collection up on a separate Web Application than our website, we will need to log to our My Site independently of this site. You may now click on the My Site link!
  4. Login as spadmin and watch the MAGIC!

  5. Check it out!

  6. Close your browser, open a new one and browse to http://fbaextranet.attis.org again.
  7. Login as Employee1. You should see a My Site link in the top right hand corner of the page. Remember, this user was created in part 1. Click on the My Site link, logon as Employee1 and again, watch the MAGIC!


Caveats

Of course, this solution has a couple of caveats. The biggest issue I have come across is Search. At present time, the crawler simply cannot deal with Forms Authentication yet. This is not a problem for the main website as the crawler simply enters through another zone. The following TechNet article explains how the crawler interacts with multiple zones and authentication modes in great detail. I encourage you to read it. With that said, MySite Search does not work OOB (I say OOB because I am sure someone will come up with a clever solution at some point) because all of the MySites lie behind Forms Authentication.

Now go forth and integrate your Forms Authentication Solutions with MySites and your SSP’s. it will be interesting to see if there is going to be a supported or documented solution put forth by Microsoft. I guess we will just have to wait and see!

Office SharePoint Server 2007 – Forms Based Authentication (FBA) Walk-through – Part 1

A while back a client asked me to set up Forms Based Authentication (FBA) for them. I said sure (of course) and started to research the steps required to accomplish this. In my oodles and oodles of research I had found many useful but somewhat partial posts. What I mean by this is that not one of the posts I have encountered in my research had ALL of the steps required to get this to work, I was left to aggregate steps from different areas. Most posts assumed you were running as an administrator, maybe even that your SharePoint application pools were running as system accounts with unlimited privileges (on both the operating system and in the database), no “real world” scenarios if you will. Also, all of the posts never made mention of Office SharePoint Server, they all centered around Windows SharePoint Services (more on that later). My aim here is to provide a series of posts that include the following:

  1. Each and every step required to setup FBA using the built in Asp.Net Membership and Role providers (Part 1). I will demonstrate one way to accomplish this. There are others and they will be mentioned, but not looked at in any detail.
  2. How to enable MySites and the Personalization features included with Office Server and have them actually work with a site using (FBA).
  3. A natural extension of 1 and 2 that will demonstrate how to hook into the ADAM membership provider, and get it functioning with MySites and the Personalization features as well.

Initially, after setting FBA up successfully (Part 1), my client then asked me to enable MySites. That’s when all hell broke loose. Not only did this not work right away, but after 3 unsuccessful calls to Microsoft support (they could not get it to work and kept parading me in circles, and still are for that matter, maybe they will read this and call me back), and quotes from Microsoft employees saying “it’s not supposed to work” or “it does not work”, I am pleased to say that it does in fact work and I will show you how (Part 2).

Before we begin I have to say that since I have been told that “it’s not supposed to work” or “it does not work”, and since I have not found any reliable documentation indicating how to do this, I must add a disclaimer that if it does not work for you, something is different between our environments, or to please call Microsoft . I will do my best to be as detailed as possible about my environment and all of the steps involved. If anything is unclear, please leave a comment and I will do my best to make it a little clearer. One last thing I would like to mention is that I have successfully implemented MySite functionality as well as the other Personalization features of Office SharePoint Server 2007 with Forms Authentication using both the built in Asp.Net Membership and Role providers as well as with an ADAM Membership provider. I have recently received an ADAM Role provider from Adam Buenz and plan on testing that soon but fully expect it to integrate seamlessly (with his help if needed, I hope).

So here we go, this is going to be a long one so bear with me. In the end of the series you will have MySite and the Personalization features working seamlessly with Forms Authentication in your Office SharePoint Server 2007 environment! Good Luck!

One assumption I have made in this process is that you have already created a Shared Services Provider and started the Office SharePoint Server Search service. Also, I am logged on to the development machine as a domain administrator. The term browser in this series means Internet Explorer 7. All of the below steps are to be performed on the Guest machine.

Environment

My environment is as follows. Keep in mind that any variation from this could produce different results. Again, if I forget to mention something obvious, please let me know and I will update the list.

Host Machine

  1. Intel(R) Pentium(R) M processor 1.86GHz 1.86GHz
  2. 2.00 GB of RAM
  3. Microsoft Windows XP Professional, Version 2002, Service Pack 2
  4. VMWare Workstation, Version 5.5.3 build-34685

Guest Machine

  1. Intel(R) Pentium(R) M processor 1.86GHz 1.86GHz
  2. 1.00 GB of RAM
  3. Microsoft Windows Server 2003, Standard Edition, Service Pack 1
  4. Active Directory (Domain Controller)
  5. Microsoft SQL Server 2005, Service Pack 1
  6. Microsoft Visual Studio 2005
  7. Microsoft Office Server 2007, Version 12.0.0.4518

FBA User & Role Store

Database Creation

We need a place to put our users. The Asp.Net 2.0 Membership and Role providers include a database. The steps to install the database are as follows:

  1. Open up a command prompt by clicking Start…Run, then typing cmd and pressing Enter.
  2. Switch to the Asp.Net 2.0 Framework directory by typing
    cd c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
    and pressing Enter.
  3. Type aspnet_regsql to launch the ASP.NET SQL Server Setup Wizard.

  4. Click Next.
  5. Choose Configure SQL Server for application services (the default choice) on the Select a Setup Option screen and click Next.

  6. Specify the SQL Server name (your machine name), database name to create (I used AspNetDb_FBADemo), and the credentials to use for this process (database creation). I generally prefix my Membership and Role provider databases with AspNetDb_ such that they appear together in Microsoft SQL Server Management Studio and are easily identifiable should I need to access them, such as to update Security (Step 10). Click Next.

  7. Confirm your settings on the Confirm Your Settings screen and click Next.

  8. The process takes a few seconds and then The database has been created or modified screen appears. Click Finish to close the wizard.

  9. Open Microsoft SQL Server Management Studio and confirm that the database was successfully created.
  10. One step that I have not seen mentioned ANYWHERE is to make sure that the account that is running the application pool that will be used by the sites you create below have access to the database we just created. This step is critical as SharePoint will NOT be able to find your users and roles if it does not have the permissions to look for them. This step is what I like to refer to as the MAGIC step that no one tells you about, so I am ruining the surprise and telling you the secret. You will thank me later.

User and Role Creation

Microsoft has given us a great database schema to use as a membership and role provider data store but has not really supplied a “good” tool to manage its contents. When you think about it, this actually makes sense. The providers are intended to be used by other applications so maybe one of the assumptions made was that the tools to maintain the users and roles will be provided by the applications that consume them.

Thankfully, the Microsoft Visual Studio 2005 team had the foresight to create a somewhat rudimentary web application to help us manage the membership and role provider data store. The caveat is that the tool must be launched from Microsoft Visual Studio 2005. You can immediately see that this is not a very good option for those that will be managing the users and roles, i.e.: real users of your application.

I will now walk you thru a set of steps to create a few users and roles that we will be using later.

  1. Create a folder on your desktop called FBA Management Site.
  2. Open Microsoft Visual Studio 2005.
  3. Select File…Open…Web Site.
  4. In the Open Web Site dialog, choose the File System icon on the left side of the dialog, then browse to and select the FBA Management Site folder created in step 1.

  5. Click Open.
  6. In the Solution Explorer, right-click on the web site and select Add New Item.
  7. Select Web Configuration File and click Add. There is no need to rename the file, web.config is fine.
  8. Replace the empty element with the following snippet. Be sure to replace both
Advertisements

One Response to Connecting Web Parts in SharePoint Portal Server 2003, Part 2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: