Categoría: security

Claim-based identity (part#2)

Before diving into the ws-* protocols I mentioned in part#1, is important to review two important concerns about exchanging messages over the net:

  1. How can I be sure that the message I get has not been read or modified along the way?
  2. How can I be sure about who sent a message?

Point (1) can be solved by signing the message and point (2) by encrypting it. In the following paragraphs I will explain this topcis in a simplify way

Note: the following concepts can be applied in several different ways to resolved the mentioned situations.

Message Signing

Let’s suppose that Endpoint A needs to send a message to Endpoint B.

Endpoint A starts by taking the message and applies it a hash function (typically MD5) (step1) and the result of that is encrypted using A’s private key (step 2) obtaining a signature for the message. After that message is ready to be sent along with its signature (step 3). When endpoint B gets the complete message, it starts by separating the message itself from the signature and applies the hash function to the message (step 4) obtaining a hashed message. At the same time B decrypt the signature using A’s public key (step 5) and as a result of the decryption is should get the hashed message. If the result is not same that are to possibilities: the message has been modify or it was sent by someone else other than A.

image

This way, endpoint B can be sure that the message was sent by A and that the message has not been altered.

Message encryption

Now supposed that A needs to send a confidential message to B.

To ensure the message to be read only be B, A encrypts the message using B’s public key (step 1) and then put it on the wire (step 2).  When B gets the message it can decrypt it using its own private key (step 3).

image

By combining these two techniques we can ensure the integrity and confidentially of the message, in other words: only the endpoint know about the data of the message (because is encrypted) and the receiver of the message can be sure about  the recipient and content of the message (because it is signed).

To be continue…

Claim-based identity (part#1)

During this week I ‘ve been working with federated identity a very interesting topic that every day sounds more and more. This post is the first part of a quickstart I plan to write to help beginners to understand the stack of protocols involved in the solution to this common problem and in particular to Microsoft’s solution for it: codename «Geneva».

Let’s start by getting familiar with some vocabulary:

  • Security token: it is a serialized set of claims that in most of the cases is digitally signed by an issuing authority.
  • Issuing authority: any entity you trust.
  • Security Token Service (STS): is a software component (exposed by an issuing authority) applications trust for authetication.
  • Relaying party (RP): is an aplication that trust in the STS.
  • Claim: information about the user contained in a security token and required by a application (RP app.). In some point claims are analogous to attributes in the enterprise directory world.
  • identity provider STS (IP STS): is an STS capable of authenticate users, determining user identity tipically by validating his credentials (username & password).
  • Relaying party STS (RP STS): is an STS that relies in others STS to authenticate users and has the ability to generate the claims required by the relaying party application.

What is Geneva?

It is a set of Microsoft tecnologies that implements the shared industry vision for an interoperable identity metasystem. It comprises 3 components:
  • Geneva server (ADFS)
  • Windows Cardspace Geneva (CardSpace)
  • Geneva framework (Windows Identity Foundation)
If you are thinking in implementing an identity solution you must take a look at Geneva. Good starting points are the Identity Training Kit and this white paper. Depending on what you plan to do it is possible you need to understand how the things work under Geneva’s hood, I will try to give you some ligth about it starting by some web services protocols.

WS-* protocols

WS-* is a set of interoperable protocols to solve common concenrs (like security and confidentiality) when building enterprise applications. When  working with Geneva some of this protocols are involved:
  • WS-Security: is a protocol that define some extension to SOAP that can be used when building secure Web services to implement message content integrity and confidentiality. (see ws-security specification)
  • WS-Trust: is an extension to WS-Security that defines methods for issuing, renewing, and validating security tokens and ways to establish assess the presence of, and broker trust relationships. It is used by STSs to expose endpoints. This video by Vittorio Bertocci explains this protocol in a very clear way, or you can also read the ws-trust specification.
  • WS-Policy: provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. In out context it is used is used by RP app/service to expose the required policy to be invoked. (see ws-policy specification)
  • SAML: is an XML-based standard for exchanging authentication and authorization data in the kind of tokens. Our tokens are expressed with SAML.
  • WS-Federation: is based on WS-Trust and provides some extentions interesting extension that amogn other things, define how to work with passive relaying parties like web browsers. This paper by Microsoft and IBM is a very good introduction to this protocol and the whole flow of messages in the authentication scenario.
If you prefer a single point of introduction instead of jumping among the provided links, I recommend you the book by Cabrera & Kurte called Web Services Architecture and Its specifications (ISBN: 978-0735621626) (watch out! it does not cover all the mentioned protocols but despite of that is a good starting point)

To be continue…