I recently completed a large document management system on SharePoint 2010 that used FAST Search and claims-based authentication. The client wanted to secure and limit access to customer-specific documents based on data coming from their CRM system.

We decided to implement a custom claim provider that would query the CRM system at login for customer claims based on the user ID. On upload (based on the customer that was assigned to the document), we used the content organizer to route the document to the correct site, library and folder based on the organization and security rules that we had. Each library had a claim for the customer assigned to it so only users with that claim could view the documents in the library. We would use search for the UI so that the users had a single place to find and view the documents. Sounds simple, right?

It should’ve been.

Unfortunately, the implementation was anything but simple. From the beginning, we hit the core limits of SharePoint 2010, FAST and Claims. Now that we’ve made it to the end, I want to talk about the limits we ran into and steps you can take in your design to avoid them. Read More…

Swiss army knife

Here at AIS, we’ve found Windows Azure Blob Storage to be an inexpensive, fast hosting solution for non-text or server-side loaded resources. But what if we want to use client-side JavaScript to load HTML fragments or JSON data directly from blobs? Under normal circumstances this is prevented by JavaScript’s Same Origin Policy; that is, you can’t load HTML fragments or JSON from another domain, subdomain, port or protocol.

One commonly used solution to this restriction is JSONP, but this is not available with Azure Blob Storage. Another modern option is Cross-Origin Resource Sharing (CORS), but it is also unavailable on Azure Blob Storage and not supported in some legacy browsers.

We could consider a server-side solution, such as employing an Azure Web Role to read text-based content from blob storage and serve it up from the original server. But this approach can be both wasteful and performance inhibiting.

Read More…

Video has become an integral part of our web experience.  This, coupled with the pervasiveness of connected and video capable devices, calls for an easy-to-use, flexible, reliable and scalable platform for hosting, processing and distributing media to anyone, anywhere, on any device.  The availability of Windows Azure Media Services (WAMS) Preview lets us explore a promising new platform which aims to bring us closer to that goal.  

Since WAMS is still in the preview release stage there are a few wrinkles in the platform that early adopters need to be aware of.  These issues should be corrected in upcoming releases but until then, there are a few alternate approaches that will help you get your media solution up and running with as little frustration as possible. In this post I will show you how to get video content hosted, encoded and delivered using the WAMS SDK and how to work around some of the quirks with the June 2012 Preview version.

Read More…

One of the most discussed concepts about authentication today is the concept of Single Sign-On, or SSO. SSO is the ability for a user to log into one location, and authenticate across several domains without entering any additional credentials. This saves the user from having to enter several credentials for related websites, as well as possibly prevent the user from having to remember multiple logins.

While developing the Rolling Stone and Vogue Archives, we needed a SSO system that could integrate our ASP.Net based archive with each provider’s existing authentication systems, primarily Apache-based web applications. Our solution was to develop a C# implementation of mod_auth_tkt cookie-and-token based authentication system, which we have since released open source.

Read More…

One day, not so very long ago, Kevin and Tom stopped by for a visit and asked me, “Can we build a low-cost Content Management System (CMS) on .NET that serves up audio and video content? The site also needs to sell access to the A/V content, and oh…the CMS users will be non-technical and it has to work on the iPad too.” I replied that of course we could build such a system and would get back to them with a plan.

Then I thought: What did I just promise?

Read More…