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.