In the Identity Metasystem, claims are produced by issuers and consumed by relying parties (named service providers on other models). A security token is the data structure that holds the claims during the communication between these two parties. However, a security token is more that a mere container of claims. Typically, it contains the metadata required for two important functions:
- Securely associate the contained claims with their issuer.
- Securely bind the contained claims with the subject of these claims.
Typically, and for efficiency reasons, this metadata is not individually defined for each claim.
How are tokens associated with an issuer?
The association between a token and its issuer is normally (there are some exceptions) done using digital signatures: the token contains the signature of its content, verifiable using a key associated with the issuer (e.g. the issuer’s public key).
How is identified the subject of the claims?
The two commonly used methods for binding the claims to its subjects are:
- Bearer – The holder of the token is the subject of the token’s claims. This is similar to the concept of bearer check. Namely, it has the same problems as bearer checks: anyone that gets the token can pretend to be the token subject.
- Holder-of-key – The token claim’s subject is the entity that proves to possess a key specified in the token.
Associating tokens to messages
Security tokens are used to authenticate message originators, i.e., to obtain a claim set of which the message originator is the subject. Examples are:
- Web applications: authenticate the HTTP request originator
- Web services: authenticate the SOAP message originator
In the web applications context, the security token is simply added to the HTTP request (see the “A Guide to Using the Identity Selector Interoperability Profile V1.0 within Web Applications and Browsers” for an example). Since a typical browser does not have the ability to sign HTTP requests, the simpler (and more insecure) “Bearer” method is used.
In the web service context, the security token is added as an header of the SOAP message. In this case, the “Holder-of-key” method is used, implying that the SOAP message contains a signature verifiable with the key specified in the token. This cryptographic binding between the message originator and the token subject is defined by the WS-Security and WS-SecurityPolicy specifications.
Concrete token types
The Identity Metasystem does not define a specific token type. Neither do the WS-* specifications. Instead, these models aim to support different token types, namely tokens based on legacy mechanisms and protocols.
The OASIS Web Services Security standard defines several profiles describing how to use different security structures as security tokens, namely:
- Kerberos tickets
- X.509 certificates
- SAML assertions
- Username+password pairs