Building a Claims Aware Environment using ADFS 2.0 and WCF

Build and Config, Design Concepts and Code, Infrastructure, Programming, Security, Technology, Web Development, Web Services and Interop No Responses »

Dec 062012

Introduction

This is going to be a multi-part series of articles with the end goal of producing a solution which handles security/identity claims across domain boundaries using WCF services and Active Directory Federation Services 2.0 (with a federation trust) and Active Directory. In order to demonstrate an approach to handling claims, we need an environment which is capable of supporting the infrastructure configuration we require.

Network Design

I strongly recommend that you put the time and effort into understanding the network topography. When designing a key foundation of your approach to security, it’s critical that you have a working knowledge of the kind of trust you are placing in your trusted sub-systems. For the next few articles, I’m going to rely on the following network design, which you can (not without some effort) establish for yourself using virtual machines:

Basic Network Design

Host Configuration

To keep resource usage to a minimum, I’ve designed my test environment to reuse hosts for key roles. In practice, you might not normally mix roles in a production environment – refer to the appropriate ‘best practices’ to properly plan your infrastructure and deployment of critical roles! Here’s a view of what is on each host:

Host Configuration

Installation and Configuration

You’ll need a minimum of two server installs to make this happen, although I’m using four to separate ADFS 2.0 and to configure an Enterprise Certificate Authority rather than a standalone CA. You’ll also need the Windows Identity Foundation (WIF) SDK installed with your copy of Visual Studio (Visual Studio can be installed elsewhere – not on your test servers).

I’ll be using Visual Studio 2010 for this, but I’m sure there’s a solution for Visual Studio 2012. To streamline your configuration, I’ve provided links two some excellent walkthroughs on the MSDN blog site – the one you need to pay attention to is the ADFS 2.0 installation and configuration.

My Mobile Configuration

Since this is a fairly intensive number of operating systems, I’ve put together a fairly decent local configuration which I can take with me. I’m using a 480 GB SanDisk SSD in an eSATA external enclosure (my laptop does not support USB 3 at the moment). I’m running VM images off the SSD and getting very respectable performance. No problems running four VMs in parallel.

How to Get Up and Running

My best advise is to follow the links below. You’ll need a fair amount of stuff downloaded, so better jump on that. Once you have some clean OSes and the installation packages, my best advise is to follow the walkthroughs. Be careful not to accidentally skip anything, the configuration is a bit tricky at times, but if you follow the walkthrough closely you should have a working environment in about half a day or less. My configuration varies to the walkthrough (as I have two domains), but if you duplicate the configuration for two different directories you should have something which can work.

Links Galore

If you’re going to build a test environment (frankly, just do it – it’s the best way) budget at least a day to get everything configured properly. Don’t cut corners, it’ll only hurt you later.
Check back soon for the next article, where we’ll start to get familiar with the environment, and build a claims-aware application.

Important Downloads

.NET Framework 4.0 Runtime
http://www.microsoft.com/en-au/download/details.aspx?id=17718

.NET Framework 4.0.3 Update
http://www.microsoft.com/en-au/download/details.aspx?id=29053
Update 4.0.3 for Microsoft .NET Framework 4 – Design-time Update for Visual Studio 2010 SP1
http://www.microsoft.com/en-au/download/details.aspx?id=29054

Active Directory Federation Services 2.0 (RTW)
http://www.microsoft.com/en-us/download/details.aspx?id=10909&hash=Hx4OGpwvFzmf7%2bC7rR1nq18CYhcY%2bSE4ok1ifL%2fvSkYIpezfAxg6ePR2zpfAplmm6g%2fUyL1VU7RtmnuR6T4NWg%3d%3d

Windows Identity Foundation (Runtime)
http://www.microsoft.com/en-us/download/details.aspx?id=17331

Windows Identity Federation SDK
http://www.microsoft.com/en-us/download/details.aspx?id=4451

Installation and Configuration Walkthroughs

ADFS 2.0 Installation Walkthrough
http://blogs.msdn.com/b/alextch/archive/2011/06/27/installing-a-stand-along-adfs-service.aspx
Establishing a Federation Trust Walkthrough
http://blogs.msdn.com/b/alextch/archive/2011/06/27/establish-federation-trust.aspx

Building a Claims-aware Web Application Walkthrough
http://blogs.msdn.com/b/alextch/archive/2011/06/27/building-a-test-claims-aware-asp-net-application-and-integrating-it-with-adfs-2-0-security-token-service-sts.aspx

These walkthroughs really helped!

Finally.. If you hit problems with your STS certificate – check the HTTPS bindings of your local IIS:

http://www.shutuplaura.com/journal/2010/1/5/adfsv2-rc-iis-certificates.html

Team Foundation Server in the Cloud (Part 3): Builds, builds, builds

Build and Config, Cloud Computing, Infrastructure, Team Foundation Server 7 Responses »

Sep 252011

Part 1	Setting up TFS Azure
Part 2	Configuring Visual Studio to use TFS Azure
Part 3	Registering Team Build controllers for TFS Azure
Part 4	Builds in the Cloud

Introduction

Continuing from Part 2, now that we have the essentials set up, we’ll take a look at how to utilize the full functionality of Team Foundation Server Azure.

Before we get too deep into the article – this from Microsoft:

5. Unable to configure a TFS 2010 build agent/controller

Unfortunately, the TFS 2010 build agent and controller is not compatible with the Team Foundation Service Preview. You’ll need to use the build server software that is part of the Team Foundation Server 11 Developer Preview. You can find information about that release here.

You’ll need to install a facet of the Team Foundation Server 2011 Developer Preview in order to configure a Build Controller and Agents.

Microsoft® Visual Studio® Team Foundation Server 11 Developer Preview is the collaboration platform at the core of the Microsoft Application Lifecycle Management suite of tools, which helps teams be more agile, collaborate more effectively, and deliver better software faster.

Anyhow, you’ll have to download the installer (choose from Web Installer, .iso or self extracting EXE). you could start downloading while continuing reading this article.

TFS Preview invite codes

I’ve had a few readers contact me in regards to invite codes for TFS Preview. AFAIK, I was able to help them all out; and I have a couple of code/activations (2-3) left.
So if you haven’t received your own activation code yet, and want to get started ASAP, drop me a line and I’ll send you one of the last codes I have which still has activations available.

Continuing Along

So when we left off, we’d configured Visual Studio 2010 to connect to TFS Azure, but now it is time to consume TFS Azure by using some of the functionality available. I’ve got a sample solution that I’ll be writing about and publishing in a later series of posts, and I’ll be using it as a guinea pig (test) of TFS Azure’s service.

Open the solution you’d like to manage under TFS Azure, connect to your TFS Azure account (follow steps in Part 2), and then add your solution to Source Control as you would for a normal solution. I prefer to add my solution structure to the source control directory before opening the solution. This makes it easier to bind.

You can check your bindings, you should be able to bind:

Now, once the solution is opened, you’ll see that the files are pending in the source control window:

As a good developer always does, I’ve run my Unit Tests and ensured that everything is peachy:

Now that everything is ready, I’ll commit my changes to the Cloud!

Assuming all goes well, you commit should work successfully, and your solution is now hosted and bound to TFS Azure.

Building

Configuring automated builds, however, pose a tougher problem to solve. First, I tried to create a build definition myself, as I would with TFS 2010. I navigated my way to the Team Explorer window and right clicked on Builds and tried to create a “New Build Definition”:

This was met (predictably) with the following (somewhat unhelpful) error message:

“TF225001: Creating a build definition requires a build controller be defined for this team project collection.”

As mentioned earlier, and according to this known issues page – you’ll need to install the Team Foundation Server 2011 Developer Preview to define build and a build controller.

So, whilst we’re sitting pretty without our solution bound to source control, we can’t create continuous integration or other automated build definitions. A pickle.

Configuring a TFS 2011 Build Service

I’ll be the first to pose this question – what’s the point of Team Foundation Server Azure (in the Cloud) if build controllers and build agents don’t also sit in the cloud? It seems totally redundant to me, to go to the hassle of binding to Azure if I must create and maintain my own build controller and agents in what amounts to off-cloud hosting.

It is my hope that this is rectified sooner or later.

Nonetheless, moving on..

To set up a build controller/agent you can follow along here, watch Richard Hundhausen’s video or read BHarry’s post here.

Install

Once you’ve downloaded and mounted the TFS 2011 Developer Preview image, you’ll need to run the TFS Server install. I realise that a separate installer for the build parts would be *far* more convenient, but you have no choice in the matter, it seems:

Once the variety of prerequisites are preinstalled (including the ominous copying of installers to the dreaded “installer cache” you’ll be prompted with the following screen:

Configure Your Build Server

Since we’re only interested in the Build Service, select it from the left hand tree, and then click on “Start Wizard”.

Once you hit the welcome page, click “Next” ton configure your Build Service installation. On the second page you’ll have to select your Team Collection, you do this in much the same way as from Team Explorer (refer to Part 2 for details).

Once connected, you’ll notice that there are no build controllers.

Clicking Next, we’ll accept the default, and have a build controller and single build agent created for us.

On the next page, we’ll be prompted to provide credentials for the Build Service to run under. Note that you can change the default port that the service will use to communicate with TFS Azure (9191 by default). You might want to ensure you’ve opened the port with your firewall (or other systems). Don’t forget to click on the “Test” hyperlink to authenticate the credentials you’ve supplied.

Also note that the service will use the Windows Live credentials you specified when you connected to the Team Collection, earlier in the configuration steps, not the credentials you specify now, to connect to TFS Azure.

Our final page is the configuration summary page. Once satisfied that your configuration is correct, press the Next button:

Once the checks have completed, click on the “Configure” button..

Once finished, you should get (hopefully) all successes. Your Build Controller is now registered with your TFS Azure account.

Finally – A Build Configuration

Now that we’ve configured a Build Controller.. we can return to Visual Studio 2010. I refreshed my Team Explorer, then right clicked on the Build item and selected “New Build Definition”. This time, a different result – success.

Now I can configure my build as I normally would. For my first build, I’m not going to bother with a drop folder, so I unchecked this option (above) and also in the Process configuration:

Building

Now I’ve saved my build configuration, I’m going to run a test build. I right click on the build definition and select “Queue New Build”:

My initial build built, but failed the unit testing. This was caused by one of the tests which launches an interactive WinForm. Commenting out this form, and checking in, triggers the automatic Continuous Integration build. With luck, everything passes the second time:

Returning to our browser, if you log into your TFS console, ensuring you aren’t in the Administration section, you can browse and see the build history now:

Conclusion

TFS Azure represents a tantalizing option for teams to share their workspaces and automated builds, but until Build Controllers and Build Agents can be hosted in the Cloud too, build services are a major weakness. It is also somewhat disappointing that the Build Server software isn’t packaged and made available as a separate installation package (less than 1 GB).

That said, I had no trouble at all in configuring the Build Service 2011 (Developer Preview) and the whole process from Visual Studio 2010 to TFS Azure to Team Build worked seamlessly the first time through, with no errors or installation show stoppers.

In the next article, we’ll look at some ways we can customize the build as well as set some more meta data, such as Areas/Iterations and team security settings. We’ll also look at how we can link build definitions into our work items and how the registered builds play a part in our overall SDLC.

Check out http://www.tfspreview.com for more information, or the community message boards located here.

Part 1	Setting up TFS Azure
Part 2	Configuring Visual Studio to use TFS Azure
Part 3	Registering Team Build controllers for TFS Azure
Part 4

Product Numbering and Branch Management

Build and Config, Process Methodology, Team Foundation Server 2 Responses »

Sep 222011

Introduction

Recently I had to determine a universal product versioning syntax for our products and services. This was done to ensure a level of consistency between projects and products. Depending on the deployment, currently there has been a wildly different format used between products and services.

Given the recent adoption of Team Foundation Server 2010 (TFS), and the use of Team Build throughout the product and service range, the new numbering format and branching strategy is designed to support the functionality TFS provides.

Methodology

The cardinal rule of build and release management is: “each build must be unique”. Without the ability to discern one build from another, a team cannot establish any baselines; nor can issues or defects be reported on, or resolved in, a specific (identifiable) release candidate.

To ensure every build is unique, every product or service release will be identified following a basic numbering format: [Major].[Minor].[Build].[Revision]. In addition to binary numbering (which accompanies files built as part of the build process), the build is identified also by the Build Configuration Name – the name and number form the unique build name within systems such as Team Foundation Server.

Note that Continuous Integration builds do not require an increment in version number (to avoid a useless increase in the signal-to-noise ratio of build numbers registered in TFS).

[Major], [Minor]

The project management team for each project will define the [major] and [minor] numbers for each release in line with project goals and the addition of features and functionality etc. Typically a production release will involve a minor number increment, although should the changes warrant it, a major revision is also likely.

[Build Number]

The [build] number is an atomically increasing number which ensures the uniqueness of each release build and label. Note that CI builds should not increment the product number. Formal builds also create a label within source control, so that the exact source can always be retrieved at any point in the future.

[Revision Number]

The [revision] number should be incremented in the event of a rebuild e.g. due to a build failure or perhaps because a build doesn’t pass smoke testing (and needs to be fixed and rebuilt). The revision number should be reset to zero once the build is accepted.

Note that TFS 2010 uses build labels throughout work items in each Team Project (for example in Bug work items) so that work items can be tied to explicit builds which have been created. These, in turn, can also be linked to automation run executions, changesets, work items and so on.

[The Build Name]

Thus our standard production build will be represented by the following naming convention:

<[Build Configuration Name + Number(Maj.Min.Build.Rev)]> Example: Widget Release Build [1.0.0.0]

Understanding Source Control

The standard approach to source control management has solutions arrayed in a specific folder structure, often defined as follows:

The following definitions are applied:

Root	The top level folder in a folder hierarchy
Trunk	Represents the main, ongoing development of a solution (or solutions)
Branches	Typically represents forks in the source control management, usually branched from the trunk

There are several different valid approaches to source control branching and without going into detail, the most common are:

Branch per Release
- Branch contains a specific product release build
- Useful for patching production releases
Code-Promotion Branches
- Specific code can be isolated for specific testing
- Useful for feature isolation development
- Reduces instances of source file conflicts
Branch per Task
- Rather than branching by feature, code can be isolated according to a specific task, such as vertical architecture changes (e.g. cross cutting concerns)
- Branch per Component
- For larger projects, individual components may be branched for independent development and release
Branch per Technology
- Useful when dealing with multiple operating platforms or versions, development can be split in alignment with different technology alignment, or environments

Generally, these approaches stem from a rationale behind change isolation – i.e. reducing the impact of change on the development of a solution’s code base. To learn more about these branching strategies, refer to the “Further Reading” section below.

Branching and Versioning Scenarios

The following are diagrams and scenarios which outline our approach to product and release versioning under branching scenarios.

Versioning Branches

Since our approach to release management dictates a unique build number per release, and typically an increment in the Major or Minor build number, we may branch source control at any time, continuing the product numbering in parallel.

This means that there may be concurrent builds of a solution with a similar – if not identical – version, differentiated by the build configuration/build definition naming.

When a release candidate is produced – and ultimately put into production – the remaining branches (or trunk, as applicable) are then incremented (typically with the minor version) so that ongoing development now represents the next logical product number.

Persisting Version Numbers

Anytime a Branch is merged back into the Trunk, the version number of the Trunk is persisted, not the branch version. The Branch can be resurrected at any time in the future, by branching from the merge change set.

If a Branch is merged into another Branch, typically the version number of the target Branch is kept.

A Release Versioning Example

Prior to release:

Trunk: 1.2.345.0
Branch A: 1.2.358.0 (branched from 1.2.298.0)
Branch B: 1.2.349.0

After a release from Trunk:

Trunk: 1.3.345.0 [Released as 1.2.346.0]
Branch A: 1.3.358.0 (branched from 1.2.298.0)
Branch B: 1.3.349.0

After a release from Branch A:

Trunk: 1.4.355.0 (branch A merged and released as 1.2.354.0 from the Trunk)
Branch B: 1.4.361.0

Patching

One of the most common scenarios involves patching a released product. Whilst normal development has continued on (on the source control trunk), a branch is created from the released code base, patched, and then the new updated release is deployed to production.

A Common Patching/Branching Scenario

Feature Isolation

Below you may observe two different approaches (labelled as options A and B) which can be undertaken to support “feature” branch releases – one scenario avoids a trunk release (option B); both are valid options no matter how many branches exist in parallel – they just require multiple source file merges.

In this scenario, the feature branch doesn’t feature the release patch until the final merge to trunk, prior to release

In this scenario, the release is made from the branch, then merged into the trunk

In general, it is considered a “best practice” to merge changes to the trunk and release as this avoids potential merges with other branches, and also means rolling changes can be included in other releases. It’s also far less messy in the long run.

Multiple Branch Releases

It is also possible to release and merge concurrent branches, although this carries a fairly large overhead, requiring merging of three (or more) different revisions of files. This has been captured in the following scenario:

In this scenario, Branches A and B are merged to the Trunk before being released

Additionally, rather than releasing from the Trunk, it is also possible to merge two branches into a “feature release branch”, prior to merging down to the Trunk. This is captured in the following scenario: