A custom STS in .NET, Part 2: An STS for the rest of us

In our quest to develop a temporary yet functional STS to tide us over we must expect that it will take a bit of work. Even with the time invested, it can still be very much worth the trouble if it means having a working STS for your developers to code against. Seeing their application working, with claims-based security no less, can and should bring tears to their eyes and make real to them the value of having it. Furthermore, there's nothing like a live example to show your manager (or higher-ups).

The role we need to fill is that of an STS. Since it is a bare-bones, quick, and temporary (but working!) solution, it need only have the following functional features:

1. Respond to WS-Federation passive requests from web applications
2. Respond via WS-Trust to active requests from web services
3. Gather claims data from live sources (database, Active Directory, or something)
4. Claims data should be correct for the requesting user/app/service
5. If necessary, provide a name/pass login page for authentication

Your specific needs may differ slightly. For instance, you may only have web apps that need security so you may not have a need for an active web service response. Or you may have all of your desktop/web apps using web services for their data needs and thus have no need of the passive response feature.

In our case, we do all authentication for the time being via Windows, the domain, and Active Directory. Basically, what happens when they log in to Windows. For this reason, we don't need a login page; by the time they are hitting apps that need claims data from an STS, they've already been authenticated. This is exposed quite conveniently to us in the form of the Kerberos token.

To begin with, let's create a new ASP.NET Web Application project. Most examples out there use Web Site projects, which are definitely easier to get up and running quickly, but for us we prefer the pre-compiled and easily source-controlled nature of the Web Application project. Make sure you've selected .NET 3.5 or 4.0 as your target version, as required by the WIF assembly we'll be using later. This means, of course, you’ll need at least Visual Studio 2008.

I've called mine "STS Web" to keep things simple. For now, don't worry about using any of the WIF-installed templates. We'll make use of that later, right now we just need a simple web app to run on a web server somewhere to be our little temporary STS. Instead, right-click your newly created project and select Add STS Reference. Just run through the defaults for now. All we really want is for it to generate the default project instance so we can steal some files.

You should now have two projects. In the second one, probably nonsensically called "STS Web_STS", you'll see it has some interesting boilerplate files under the App_Code folder. Copy all of them and paste them into your first project. Also copy the Default.aspx page (and its code-behind!) and overwrite the one in the first project. You are now free to delete the second project. We won't need it further.

Okay! We're onto something now... sort of. As it is, it doesn't really do much other than some really basic default behavior probably. In my next post we'll tackle the first task of responding to passive STS requests.