Andy Burns’ SharePoint Blog

I’d an interesting question from a customer the other day – they wanted Forms Authentication on extranet access to SharePoint, but using two factor authentication. The product mentioned was RSA SecurID, and this means that to authenticate yourself you need:

• Your Username
• A hardware device that shows a pseudo-randomly generated PIN number which changes every minute or so.

‘Cos the PIN is a pseudo-random sequence, if the token and a server are in sync, you can validate that someone has read that token inside the last minute. It’s an expensive technology – but neat!

The idea is the same as, say, a credit card. More than just saying who I am and that I have some piece of knowledge (e.g. my PIN number), I also have to have a physical object which is hard to duplicate (my credit card). This should make my identity more certain.

Anyway, how does this fit with SharePoint? Read more »

Tags: RSA, Security

Previously, I’ve detailed my attempts to show a query string parameter in a page. This should be a simple enough to do as inline code, but as my previous attempts recorded, when I tried:

<%= Request.QueryString.ToString() %>

I got the error “code blocks are not allowed in this file”. This makes sense, as otherwise anyone with SharePoint Designer could put arbitrary code into a page and get it to run. Clearly, as this would let business users enter code, this would not be very secure.

Now, you can turn off this security restriction using Page Parser Paths, but this reduces the security of the system – again, anyone with SharePoint Designer could put code in without review/authorisation. Again, less than ideal.

Well, one of the things I learnt last week was that uncustomised pages (or ‘ghosted pages‘ for the oldies) will run inline code. Fantastic! After all, we’re going to want to package up our code for deployment from Development to Testing and Production systems, right? (Well, you should be, dammit!)

For those of you who don’t know, uncustomised pages are ones that are stored on the server’s hard drive, rather than in the database. To get onto the hard drive, someone has to install them, which means that someone has to review and approve the code. With SharePoint designer, this isn’t the case, and SharePoint Designer can only create pages that are Customized (or Ghosted), and so exist only in the database.

So overall, the process would probably become:

1. On a development system use PageParserPaths to enable inline code. As this is a dev system, security is less of an issue, and business users won’t be making changes.
2. Develop your pages that use inline code. You can do this in SharePoint Designer.
3. When the pages are complete, copy them out and package into a feature. Make sure that your page that you’ve written in installed Ghosted – still the terminology they use in features.
4. Install and activate the feature. As your page is now uncustomised (or ‘ghosted’), it will now run inline code without PageParserPaths being configured.

That’s a pretty tidy developer story!

Tags: Security, SharePoint 2007 Development