Reza Alirezaei’s Blog

In Part 1 of this series, I gave you a quick tour of how to enable anonymous access and explained some of the issues regarding anonymous access in both Authoring and FBA zones. In this post I am going to walk you through some of the solutions and workarounds and also the drawbacks of each approach. In part 3, I am going to put everything together and come up with a more real life solution.

Solution 1:This solution is probably the easiest one to overcome the limitation that anonymous user is not a real configurable identity in FBA zone. It is all about making SharePoint think that anonymous user has logged in under the security context of whatever you construct in ‘Global.asax’ .Yes, the ‘Global.asax’ file in the FBA protected site must be modified, so that the ‘Application_AuthenticateRequest’ event (To authenticate the caller) knows how to construct a valid cookie and assign it to the current unnamed identity (anonymous user). This will be later used by the SharePoint downstream authorization process to define what level of access control an anonymous user has to various resources across your site. You simply add the Guest account to your identity store and replace ‘Global.asax’ of your FBA site with the one below and BINGO! anonymous users will show up as “Guest”. Now , You can target content at “Guest” and you can assign permission. Easy, huh?

This solution can be found here . Here is the gist of it – implemented in ‘Global.asax’ :

Drawbacks : First of all It only works in FBA zones. Secondly, many people may not want to add that Guest account in their identity store (for whatever reason) so that would be ideal if we could somehow virtually create that Guest Account. This will lead us to the second solution.

Solution 2: This solution is actually an extension to the above solution by leveraging a custom authentication provider behind the scenes and by virtually creating the Guest context (It’s called Annon in that post). As I alluded to earlier , the whole point here is not to have a Guest Account in the underlying identity store instead virtually creating it at runtime. This POC is very well documented so there is no point for me to reinvent the wheel. Go ahead and read up for yourself, but make sure that you come back and read the rest of this article 😉

Drawbacks : Like the first solution it doesn’t solve the issue we saw in Part 1 with regards to NTLM or Kerberos protected sites , it is only for FBA protected sites period . On the other hand, it is a proof of concept (actually a brilliant one) , but in reality you have to merge this POC into your already developed custom authentication provider , right? Otherwise what’s the point of having an authentication provider that only returns one user (Annon user)?! Plus , that would be great if we could package the whole damn thing into a feature that can be turned ON and off that gives you more flexibility. In part 3, you will see how I will combine all these solutions to make a much more kind of production ready functionality.

Solution 3 : Wrap the content in SPSecurityTrimmedControl and then you should be able to target it to different SPBasePermissions or AuthenticationRestrictions. In the example below, the entire web part zone is surrounded with SPSecurityTrimmedControl tag with PermissionsString set to CreateSSCSite (Self-Service Site Creation) . The “CreateSSCSite ” permission is common to the “Members”, “Owners” and “Visitors” group permission levels, but is not set for the “Limited Access” permission level which is assigned to anonymous users permission level. As you can see, thumbs-up picture doesn’t show up for anonymous users.

Drawbacks : The main drawback of this approach is that it is mainly useful for content targeting and anonymous users still cannot fully interact with document libraries as we discussed in Part 1. CreateSSCSite is also not granted at “Quick Deploy Users” which means people in that group will also treated like anonymous users. If you can live with that limitation then this solution can be an option for you.

These days many public-facing sites allow users to view pages and perform some limited actions anonymously against various functionalities those site offers to their audience. Turning on anonymous access really requires thorough considerations and planning in advance because everyone visiting your site will be able to access the landing page at minimum and from there they have limited access to other parts of your site. This potentially can lead to a situation in which unauthenticated users can contribute to your site to an extent, use up server resources, discover users personal information and the content that you may not want them to be exposed to the public. Fortunately, in both Moss and WSS , you not only have the option to enable/disable anonymous access , you also have a fantastic granular control over how anonymous user experience should be when interacting with your site. This makes it a lot easier to turn a SharePoint site to a public-facing site exposed via internet which was one of the main goals in WSS 3.0 and MOSS 2007. In this article, I would like to give you a quick tour of how to enable anonymous access and what issues you or your anonymous users might face during this exercise. In part 2, I will be writing about some of the existing workarounds and solutions and finally in Part 3 I will be demonstrating how to turn them all into an even better (more real life) solution by coding the missing parts.

Through out these articles I assume that you have a basic understanding of forms based authentication (a.k.a FBA), you have created a site in default zone (a.k.a authoring zone) and extended it to an Internet zone (a.k.a public facing zone). Your default zone in protected either by NTLM or Kerberos and your internet zone is using a custom authentication provider. Now that you are ready , let’s get rolling!

Anonymous access must be granted at the web application level at the time that you create the web application and zones. It is a check box that you select and the end result is a <allow users=”*”/> element that is added to the web.config of the Zone for which anonymous access is enabled. Yes, you can always go back and enable or disable this by going to “Authentication Providers” page in Central Admin as illustrated in picture 1.

Picture 1

Here is what would be added to the web.config when anonymous access is enabled.

For anonymous users to be able to get to your SharePoint site via internet they have to cross two barriers:

I) IIS barrier : As I alluded to earlier, IIS barrier is handled in the web.config when you set up the zone to allow anonymous access in Administration Site.

II) SharePoint barrier : Site Administrators have to tell SharePoint to allow anonymous access by browsing to http://yoursite/_layouts/setanon.aspx and granting the right access control for anonymous users (Picture 2). You need to repeat this for all sites unless permission inheritance is turned on.

NOTE: if the <authorization> tag is not present in the web.config, then setannon.aspx has all its options grayed out.

Picture 2

In additions to the settings in setannon.aspx page , each document library or list has separate settings for anonymous users in order to control how they can access and interact with the content.

Document Library :

Picture

Custom List (Called Annon List):

Picture 4

As saying goes, the devil always lies in the details. Okay , what are the problems regarding the annonymous users in SharePoint? I am glad that you asked!

1) Anonymous access relies on the anonymous user account on the web server (IUSR anonymous account).

• In an FBA scenario where users are authenticated against a custom identity store and not AD , there is not a real configurable identity for anonymous user. This makes audience targeting at anonymous users (MOSS only) a bit challenging. For example when showing a web part targeted at people who have not signed in or a message shown to anonymous users only.
• Even in the default zone where IUSR anonymous account can be resolved, audience targeting at this account won’t work.

2) No matter what kind of permissions you grant to your anonymous users , there are still some restrictions when they interact with your site:

• Anonymous users can not upload, edit or attach files in Document libraries including Wiki libraries. This applies to both your authoring zone (which is always supposed to be protected by Windows Integrated Authentication) and FBA zone such as Internet zone. Look at the picture 3 above and note how some of the options are grayed out by default.
• Anonymous users can not fully contribute to Lists, discussions or surveys. For example , they cannot attach files to the list items (FBA zone only). As shown in the picture 4 above , in custom lists you can specify that Anonymous users CAN add items to a list. Well, an item might include an attachment right? , but in actuality when they attach a file to the item they will be redirected to a log in page. It simply means that they CAN NOT. 😉

I have tried above limitations in our custom list and for both zones. below is the result:

Picture 5

I don’t really mean to insult your intelligence , but just as FYI , thumbs are not part of the List – I just added them to the picture to show you which operations went through without requiring anonymous user to log in 🙂

3) (Credit to Doug Ware – See his comment below and his post here) Turning on anonymous access in one zone has the unfortunate behavior of giving all authenticated users the same rights as an anonymous user on all of the zones in the web application.I (as Doug Ware :)) encountered this recently when I had one zone set up that did not allow anonymous access and the Restricted Read permission level. I extended the site to another zone and configured it for anonymous access to the entire site. The members on the original zone were then able to browse the list because the configuration gave them more rights than Restricted Read even though the zone they were using was not configured for anonymous access! Based on my reading of the documentation it was by design.

Now that you know some of the issues with regards to anonymous access in SharePoint, let me walk you through couple of solutions in part 2.

DevTech team has released the name of final speakers and their topics here and it seems that I also made the cut to speak at this event. DevTeach / SQLTeach Toronto 2008 will be the biggest developer, DBA and ITPro conference in Canada. It’s jam-packed with advanced sessions (level 300 and 400) all on the latest versions of Microsoft products and technologies. I am presenting two topics in the SharePoint track:

1) Accessing External Data Sources Through SharePoint:

Imagine that your SharePoint sites must contain structured data in a high volume and you need to perform complex queries and actions against it. Obviously, there are pros and cons of storing such information in SharePoint lists or in a custom SQL database. Realistically speaking, neither of these approaches alone nor Business Data Catalog (a.k.a BDC) is the answer to all of your data integration woes. You like the versioning, approval, bulk editing , rich UI and other good features that SharePoint lists offer but you are also concerned about the performance of your complex cross-list queries, CAML limitations (like ‘join’ , ‘Select distinct’) and optimized searching. You need to provide a common metadata repository and a hybrid framework for accessing external data sources through SharePoint utilizing all your options including BDC, Data View Web Part and custom code to keep both data structures in sync. In this session I will show you how you can surface information from your backend databases into your SharePoint sites, when to keep structured data in SharePoint lists and when not and eventually how in real world implementation you will end up combining all your options to come up with a robust solution with much better performance!

2) Forms based authentication in SharePoint with the SQL Server membership provide :

In ASP.NET 2.0 , there is an important concept called provider model which is used for many new feature such as Membership/Role Management, Profiles, etc. SharePoint is built on the top of ASP.NET 2.0 which means it can utilize everything that ASP.NET 2.0 offers including SQL Membership provider. In this session learn how to set this up, get yourself familiar with issues/workarounds, managing your custom profiles and finally how to leverage this solution for exposing your SharePoint sites to external users. This is an advanced session, targeting both IT Pros and Developers and attendees will receive fully commented source code with step-by-step walkthroughs for the exercises shown during demo.

A web part that has its own toolbar with different controls added to it programmatically is easy to build.

1) Create a web part and override CreateChildControls and Render methods:

2) Create the BtnTemplate class that implements ITemplate interface. Add all the controls you want to show up on the toolbar

3) Finally,deploy your web part and you are pretty much done! Here is how your web part looks like.

Source Code can be downloaded here.

Update 13/Sep/2008:   Another way of adding toolbar is now documented here.

Since I am a lazy developer I normally don’t like to author multiple stored procedures if I can afford to aggregate all the logic in one place without causing too much complexity. For example when working with custom authentication providers you are often required to write separate stored procedures for GetAllUsers, FindUsersByName, FindUsersByEmail that can be called from their counterpart overridden methods in your custom authentication provider’s code. Following example demonstrates how you can have one stored procedure that can handle GetAllUsers, FindUsersByName, FindUsersByEmail logic in one stored procedure. As shown below, @email and @username parameters can be null which means you can ignore these two filters and get all the users instead. One important thing to note is the table that holds all the user information in this example. It is called Contacts with ContactID as the primary key, but yours might be different! Read more…