If you want your application to externalize user authentication to a Security Token Service (STS), you must consider:

• How are you going to identify your application to the STS?
• What type of security token are you expecting?
• What claims do you expect inside the token?
• What endpoint should your application’s users send requests for tokens?
• Do you want the STS to encrypt the tokens it issues (to ensure that others cannot inspect the tokens’ contents)?
• How can your application verify the origin and integrity of the tokens it receives (to ensure that the tokens were issued by the STS and were not tampered with in transit)?

Most or all of these questions must be answered in order to establish trust between the STS and your application.

Setting a trust relationship, as we mentioned above, implies interchanging different pieces of data such as digital certificates, uniform resource identifiers (URI), and endpoint addresses. Some of the feedback we received regarding “Geneva” Server’s predecessor, Active Directory Federation Services (AD FS), indicated that setting up these relationships was cumbersome and very error prone for users, especially when it came to typing URIs or choosing the right certificates to send across. Resulting errors are difficult to diagnose, especially if multiple organizations are involved.

Our goal with this series of 3 posts is to talk about how the features we have implemented in “Geneva” Server and “Geneva” Framework simplify trust establishment.

What does “establish trust” mean?

Let’s look at a couple of scenarios.

In the first scenario, suppose that a user needs to access your claims-aware application that requires a token from an STS inside your organization. As we mentioned before, the STS and the application have to trust each other:

The trust relationship between STS1 and Application1 needs to be configured at both ends:

• STS1 issues tokens for Application1. This means that the STS needs quite a bit of information about the application, including:
• The list of claims that it understands. Each claim type is represented as a URI.
• What type of token the application expects to be issued.
• The URIs identifying the application.
• Whether it expects the tokens encrypted and, if so, which certificate the STS should use for encryption.
• For certain scenarios, the URL of an endpoint at which the application is listening.
• Details about the supported protocols.
• Application1 accepts tokens issued by STS1. This means that the application also needs quite a bit of information about the STS, including:
• The list of claims that it may send.
• The certificate(s) with which the STS will sign its tokens.
• The token types (represented as URIs) that the STS supports.
• The protocols (represented as URIs) that the STS supports.
• For certain scenarios, a URI identifying the STS.
• For certain scenarios, the URL of an endpoint at which the STS is listening.
• Details about the supported protocols.

In the second scenario, you want to reach another claims-aware application that is deployed in a different organization; the most common deployment pattern is to use two STSs where one is in your organization and one is on your partner’s premises:

As in the previous scenario, two trusts must be configured so that:

• STS1 issues tokens for STS2.
• STS2 accepts tokens issued by STS1.
• STS2 issues tokens for Application2.
• Application2 accepts tokens issued by STS2.

The information that needs to be exchanged is the same as in the single STS scenario.

How does “Geneva” make this easier?

With the beta release of “Geneva” Server and Framework, we have simplified this experience and significantly reduced the number of manual steps needed:

• All the data required to establish trust (Federation Metadata) has been represented in a common format based on industry standards.
• “Geneva” Server publishes metadata at an endpoint and reads metadata exposed by other security token consumers or producers. Administrators setting trust only need to type in the metadata document URL and follow a simple wizard.
• Developers creating claims aware ASP.NET applications can use a tool that comes with “Geneva” Framework called “FedUtil”. This tool generates metadata of the application and imports metadata from the STS.

In the next two posts, we will talk in more detail about how to configure ASP.NET applications to accept tokens issued by an standards-based STS (such as “Geneva Server”) using “Geneva” Framework and how to create trust relationships with Identity Providers and Relying Parties using “Geneva” Server.

We look forward to receiving your valuable feedback.

Thanks!

Ramiro Calderón

Software Design Engineer in Test

“Geneva” team