Building a Security Token service (STS) using the Geneva framework

This article is based on a pre-release version of the "Geneva" framework. All information is subject to change.

This article describes the following:

Implementing a security Token service using the Geneva framework

Federated Security

Declaration conversions

This article uses the following techniques:

Windows communication Foundation, asp.net, Geneva framework

The Microsoft claims-based Access (CBA) platform strategy (code-named "Geneva") includes the "Geneva" Framework, "Geneva" server, and Windows CardSpace "Geneva". The Geneva Framework provides developers with tools to build claims-based applications and services that include tokens issued by the Security Token Service (STS), as well as tools to build custom STS and CardSpace-enabled Windows applications. Although the Geneva server is an enterprise-class STS, the Geneva framework can build custom STS for environments that do not require enterprise-level functionality. Windows CardSpace Geneva is evolved by Windows CardSpace, which is the identity selector and identity provider in Windows client computers.

In my last article on the Geneva framework, I discussed a better way to build claims-based Windows communication Foundation (WCF) services by using tokens issued by STS. Here, I'll use the Geneva framework to build a custom STS.

Before continuing with this article, we recommend that you read the Geneva Framework Developer White Paper, co-authored by Keith Brown and Sesha Mani, and my previous article, "The Geneva framework builds a better way to build claims-based WCF services."

Getting Started with security token services

Either STS based on the Geneva server or STS built using the Geneva framework, the primary role is to authenticate the caller as a security gateway and issue a security token that describes the caller's declaration. From the previous article, you should be able to recall that STS authentication supports multiple scenarios:

Isolate applications and services from the authentication mechanism so that they can focus on authorization-related declarations.

Supports multiple credential types without complicating the implementation of applications and services.

Supports federated scenarios, where users can gain access to resources in another domain by authenticating in their domain (by establishing a trust relationship between STS in a different domain).

Simplifies the identity delegation scenario, and authenticated users gain access to downstream services.

Simplify declaration conversions so that relevant declarations can be used to authorize applications and services.

Any of these scenarios can be based on passive syndication (browser-based) or active syndication (windows-based clients). I'll explain these scenarios in more detail, along with how to use the Geneva framework to build the logic in the custom STS.