I'm here at VS Live with Josh Holmes. Josh could you please introduce yourself, tell us who you are and what you do?

My name is Josh Holmes and I am a Principal in SRT Solutions. SRT Solutions is a Consulting firm in the Michigan Area. We do different type of work, Smart Client to ASP.NET. We have brought the best from various topics and areas to a center-point in SRT Solutions. We've got Bill Wagner who wrote Effective C Sharp and is extremely good with Scientific Applications, Smart Client. Then add in my expertise with big iron on ASP.NET applications and mobile devices in pushing that data out to where it is needed by our clients. That's SRT solutions.

One of your focuses is on security especially in the ASP.NET world, and you mentioned that authentication is basically a solved problem.

ASP.NET 2.0 really does solve the problem and at this point authentication is a drag-on control. It is solved, it is done. Microsoft realizes that they've written the same code a thousand times, so why not just wrap it in a control and drag it on to the form and you're done. It automatically wires up to the membership provider or the role provider, and at that point you've got your authentication portion done so why do you need to solve that problem again?

Once the user is authenticated, the next problem that is not so well defined at this point is authorization. What should be the guidance?

The guidance on that is that isEnrolled() is used a lot but you really want it to be more administrative so you really want to move that authorization into database driven or web.config driven scenario. That is almost a solved problem, it is not as quite well defined as the membership provider but the world based provider will read from the web.config currently; but you can provide your own based providers that will overlay what's in the base with what's on in the web.config, so your users can log in and as they wandering around your application you're hitting the database and finding what they're actually allowed to see. For instance, in a time tracking application that I recently was working on, the principles/owners of the company and the project leaders are allowed to see all the projects and all of the clients that are available in the system, but the workers are only allowed to see the projects they are assigned to. They are not allowed to see billing rates and that gets down to a more granular level where the principle that is in role inside your code behinds is very important.

What do you do in the ASP.NET space to wire up for authorization seamlessly?

That goes back to the world based provider. The world based provider is available in all of the different controls and forms, pretty much everywhere. That is going to tell you what roles individual people are in. Each of the individual bits of data that are available to your application and each of the individual forms and controls are showing some bit of data. They can decide at runtime "I'm going to allow you to see this or I'm not going to allow you to see this" based on where you are and what you are. That also needs to play back into your business ethics. Too many people put too much code in the user interface for that authorization, for who's allowed to see what and protecting things. It really needs to start further back in the business object layer where the business object layer is starting to apply those rules on what individual people or what individual roles are allowed to see and not just ... up to the front. We don't even load those controls that are going to show that data that would be sensitive. Push that information back into the business layer. How do you do that? That's not quite as well defined. You need to start passing back the set of roles that this user is in and asking for permission to see something.

You mentioned that there's the built in authorization providers, you also mentioned that we can create a custom provider. Have you got an example of that?

The quick idea is that right now form based authentication does role based security on what's in the web.config. It looks in the web.config and says "is this person alive to see what's in this directory or this particular file". That's all web based config or web.config based and it is driven by some administrators opening up a text file and editing it or running the administration wizard and working through it that way. However, that really should be database driven so that you can handle it at a much more high level and you're not actually making changes in that front-end UI logic, but you're actually making database changes in the back end. In effect, you say "you're not allowed to see this data" whether it is coming through our winforms and through the web or our mobile device so that the business layer is dealing with that instead of pushing that out of the web.config. If you're making that type of a change you're going to have to provide your own base provider because they don't have that built in right now. On the membership side of things again it connects up and wants to talk to SQL Server. Is that a good thing or a bad thing? It depends. A lot of times that's not a very good thing at all, because it means your UI is talking directly back to your client. One of the very simple quick custom providers that I did was web service based: membership provider and role based provider. I'm actually using the same database; I just keep it in a central location and use it across many different applications and many different servers and it's talking back via web services.

How do we get authorization and authentication integrated for FTP or Telnet?

The reality is that when somebody's coming in via FTP and is trying to get to your valuable data there's no built in solution for authorization and authentication that will say who's allowed to see what because of those things work on HTTP and work on that front door with ASP.NET. The answer is you need a lock down that would say "you're not allowed to see this or you're not allowed to get in via FTP or telnet, command prompt or any of these other mechanisms".
One of the examples here is that a lot of people have been keeping connection strings into their web.config; in ASP.NET 1.0 and 1.1 those are clear text. This is a huge problem. They go through all these links to secure that front door, but then somebody comes in with a simple script and gets that web.config. Now they have direct access via the connection string to your backend database. At that point your game is over. They bypassed all of your security business logic. What do you do?
There are a couple of different things you can do. One of those is you can use the brand new feature, the partially encrypted web.config where it would actually encrypts a portion of your web.config and replace that section with an encrypted data tag that includes an encrypted value. It's just the aspnet_regiis utility, you pass it ‘pe', the section that you want to convert to the encrypted data as well as the virtual application name. That will encrypt that portion of the data, all these following W3 specs on how to do xml encryption. All of a sudden there are all these different tools that can read this if they know how to decrypt it. Well, ASP.NET happens to be one of those; at run time it will load that file on encrypted portion that it needs to un-encrypt and leave the rest of them in place, encrypted in memory until they are needed. Then it will start using those as if they were unencrypted.
That's a very slight performance set but not enough that anybody is going to care because it gets unencrypted that first time then it's compiled in memory. But if anybody gets to that text file there's still SOL. The other idea is to put it in the registry, encrypt it there; you can use the DP API; it is called the protected data class, it's in System.Security.Cryptology.ProtectedData is the actual name, but I'm not sure, I'm going to have to look that up. It's got two static methods: protect and un-protect that use the machine key or the local user and will encrypt it. The nice part of the machine key is that once you take that file off the box, even if they are able to FTP that file off there's no way to decrypt it. That's a wonderful thing. So take thoughts on what are those family jewels and make sure that all methods of access are protected and encrypted and locked down and secured. Don't just think you're secured from the front end because that will get rid of the script kiddies but the real hackers are going to try many different doors.

Great. Thank you very much for sharing your time with us and good luck with the rest of the conference.

Thank you very much.