Key Background Concepts

There are a few key concepts required from various security areas that will be helpful. The concepts below are selected from a vast vocabulary used in digital security and are included below because they are helpful in understanding the contents of this document. The basic model is that a "client," like a web browser or a command line application, wishes to access a resource on a "server."

• Digest: A digest is calculated value (the output) derived from message data. The calculation (often called the hash function) typically produces a fixed size output regardless of the input size e.g. 1 page of text or 100 pages of text. A digest is also called a fingerprint or checksum. While the output can be thought of a very large number it is often described as a "string."

• Digital Signature: A digital signature is a value computed by a cryptographic algorithm that allows you to determine if data has been altered. Creating a digital signature is not the same as encrypting data. You create a digital signature of a security token to ensure that it has not been tampered with and not to obscure the content as with encryption. Digital signatures for WSS can be applied to the entire message or just parts of a message. It is typical to sign a portion of the message. If a digital signature only covers a part of the message, the signature must also include the information as to what parts of the messages are signed. Creating a digital signatures require both a formula, called a hash function, that operates on the data and a "key" (often a "secret/private key"). The hashing function calculates a digest and the key can encrypt the digest to create the "signature value." A signature value can be thought of as a very large number or equivalently as a series of bytes (a "string") inside a computer. The receiver decrypts the signature value then compares the digest value to a freshly calculated value on the same content contained in the message. If the values differ, the message has been changed.

• Claim: A piece of data and a "claim type." A claim can be almost any piece of data but obviously some data are more useful than others. For example, a claim of an "username" is useful for authentication processing and its possible that a claim of an username and the user's age (2 claims) could be even more useful. A digital certificate can be a claim, even your picture, can be a claim.

• Security Token: A security token is one or more claims where a claim is piece of data relevant to security tasks. Generally, a piece of data and a "claim type" allows you to process a claim e.g. to authenticate or authorize an action.

  Encryption: Encryption converts data from one form to another with the purpose of rendering the content unreadable without the ability to decrypt the data.

• Uniform Resource Identifier (URI): A URI is specially formatted string value that names or provides the location of a concept. For example, a claim is a piece of data and a "claim type." The claim type can be expressed as a URI. The syntax for a URI can be different between the "name" of something (called a URN) and a URI specifying the location of a resource (URL). WSS should have used URNs more prominently but the convention at the time was to use URLs for everything. Using URLs make the literature confusing because the URLs are long, complex and look like you should type them into a browser. Just be aware that most of the URLs used in the WSS specifications are really just "names" or "type" specifications much like a "type" is used in a programming language.

• Security Token Service (STS): A security token service issues and validates security tokens. Both a client, such as your browser or your web services program, and a server, such as your web services server holding resources, use a STS. The STS is almost always on a different server than the actual resource server or client and hence, communicating with the STS requires a security setup as well. A STS issues tokens that has a lifetime, so a client does not need to obtain a new token on every call to a server.

• Assertion: This word is heavily used in WSS. An assertion is a piece of data provided about something. Something, such as a server, could review your assertions and decide that it believes your assertion and issue a security token. Assertions are also annotated with a "type" so you know what the specific assertion data represents. An assertion looks like another way to say "claim" but you would choose to use the word "assertion" when your program provides claims to an STS in the hopes that it believes you and returns a security token. In other words, you assert a piece of "typed" data when you want something. If you are getting some "type data" back from the server, you would be receiving "claims" not "assertions."

  • One popular set of assertions that a client might make are captured in the SAML specification. For example, when a server receives a message containing SAML assertions, a server will look through the assertions and based on its security policies, use different assertions to authenticate the client.

• Policy: The word Policy is also used in WSS quite heavily. A policy expresses the requirements that must be met in order to do something, in our case, access resources on a server. The policies a server wants its clients to follow are expressed as policy assertions. Here, the concept of an assertion is that the server requires specific pieces of "typed" data in order to allow a client to access its resources. The list of "typed" data that the server requires are the "policy assertions." An example of a policy assertion is that a server will only authenticate a "client" if it provides a username and password or that it will only return a specific format of a security token. Policy assertions are fine-grained and used in groups. A group of policy assertions is called a "security binding."

• Public/Private Key: Keys are used to encrypt data. A public key allows the holder to encrypt data but a private key is required to decrypt the same data. Sometimes the public and private keys are the same (symmetric keys) but often they are different. You should never give away your private key if you are using different public and private keys.

The basic communication scenarios is that a "client" wishes to communicate with a "server." The server holds "resources" that the client wishes to use. The server is setup to trust a STS when it is deployed so the server and the STS know how to talk to each other. When a client accesses a server, the client is redirected to a STS to obtain a security token. The client ensures that the STS receives its "claims." Once the client has been issued a security token, it adds the token to each message it sends the server. The server recognizes the token, validates it, then if validated, provides the request resource back to the client. Because the STS server is often a different server and a client may access resources on different servers, the entire "web" of token issuing servers and resource servers forms a federation. In other words, the ability to authenticate and authorize access to resources is federated across multiple servers. The servers are potentially owned by multiple companies.

The devil is in the details, however, and there are many ways to encode or provide security information. Different methods are allowed to help fend off different threats. Security threats are always changing and can be complex, which is why web service security can become complex. Each system picks its specific set of policies it wishes its client to follow.

The requirements for authenticating with and using web services are expressed as policies. Each endpoint may have different policies depending on whether they are receiving or sending data as well as depending on what type of service is being used. At a minimum, each point in the communication path must understand how to communicate with their inputs and outputs and the policies must somehow overlap enough between two points to allow the communication to take place. A good discussion of policies and communication can be found at Understanding Web Security Policies.