Resources
- Identity Use Cases & Scenarios.
- FIDIS Deliverables.
- Identity of Identity.
- Interoperability.
- Profiling.
- Forensic Implications.
- HighTechID.
- D3.1: Overview on IMS.
- D3.2: A study on PKI and biometrics.
- D3.3: Study on Mobile Identity Management.
- D3.5: Workshop on ID-Documents.
- D3.6: Study on ID Documents.
- D3.7: A Structured Collection on RFID Literature.
- D3.8: Study on protocols with respect to identity and identification – an insight on network protocols and privacy-aware communication.
- D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management.
- D3.10: Biometrics in identity management.
- D3.11: Report on the Maintenance of the IMS Database.
- D3.15: Report on the Maintenance of the ISM Database.
- D3.17: Identity Management Systems – recent developments.
- D12.1: Integrated Workshop on Emerging AmI Technologies.
- D12.2: Study on Emerging AmI Technologies.
- D12.3: A Holistic Privacy Framework for RFID Applications.
- D12.4: Integrated Workshop on Emerging AmI.
- D12.5: Use cases and scenarios of emerging technologies.
- D12.6: A Study on ICT Implants.
- D12.7: Identity-related Crime in Europe – Big Problem or Big Hype?.
- D12.10: Normality Mining: Results from a Tracking Study.
- Privacy and legal-social content.
- Mobility and Identity.
- Other.
- IDIS Journal.
- FIDIS Interactive.
- Press & Events.
- In-House Journal.
- Booklets
- Identity in a Networked World.
- Identity R/Evolution.
D3.1: Overview on IMS
Web Services, the Claims-Based Security Model and Federated Identity Management
Introduction
In today’s world, more and more systems and applications communicate through so called ‘web services’. Generally speaking, the term ‘web service’ refers to XML-based messaging via internet protocols, such as HTTP or SMTP. The ‘Simple Object Access Protocol’ (SOAP) is the XML based protocol that provides a definition how structured and typed information can be exchanged between peers in a distributed and decentralised environment.
In order to provide security, reliability, transaction abilities and rich metadata support, additional specifications exist on top of the XML/SOAP stack. The core technologies in the XML space are all defined by the World Wide Web Consortium (W3C). Many of the higher-layer specifications are driven by multiple industry players, including Microsoft, IBM, BEA Systems, SAP and others. These specifications are helping to progress interoperability between the different industry platforms.
Figure : Overview of different web services specifications
The main theme across all these different specifications is that they are orthogonal to each other, so that they contribute to a composable architecture. Instead of having a single framework that prescribes everything from network protocols and message exchange patterns down to data formats, the specifications in the industry roadmap provide a rich set of tools to provide security, reliability and transactability for the web services environment.
WS-Security
The SOAP communications infrastructure requires additional security mechanisms for implementing the various security services. Simply speaking, the WS-Security specification provides mechanisms to attach so-called ‘security tokens’ to a message and to sign and/or encrypt the message or parts thereof. Thus, WS-Security provides message-based security that is independent of the security properties of the underlying transport channel. A security token represents a collection of one or more so-called ‘claims’. The receiver of a SOAP message or intermediary nodes can use these security tokens to validate that certain assumptions are correct. A ‘claim’ is a statement about an entity (like a principal, client, a service or a resource), whereas this statement itself could be a name/ID, cryptographic key, group membership, privilege, capability or an authorisation statement.
Example: SOAP sender could digitally sign the payload (the SOAP Body element) of the message with his private key and attach the associated X.509 certificate as security token in a SOAP Header. A SOAP intermediary like a web service firewall or the final receiver of the SOAP message could then extract the security token from the received message, validate that the claims inside the security token are valid, and validate that the security token was used to create the digital signature of the message.
WS-Security in itself defines how arbitrary security tokens can be attached to a SOAP message and how confidentiality, integrity protection and authentication mechanisms can be applied to the message, e.g. where to put the digital signature. WS-Security does not constrain what particular security tokens can be used, that is left to the various security token profile specifications. These profiles cover a wide range of different security token formats, ranging from X.509 certificates, username/password tokens, Kerberos tickets or SAML assertions to REL tokens (ISO Rights Expression Language). In the case of X.509 or Kerberos, existing binary tokens are wrapped inside XML. Besides these standardised token formats, the system is extensible so that arbitrary custom XML-based tokens can be used together with WS-Security.
WS-Security does not prescribe what particular token types have to be attached to messages, nor does it define from where these security tokens originate from. A security token could be taken from local token repositories (such as a local certificate store), or they can be retrieved from specialised security token services, such as an X.509 CA, a Kerberos KDC or a WS-Trust security token service.
WS-Trust
The claims inside a security token can represent arbitrary assertions, in which some entity makes some statement about some other entity. For example, in an X.509 certificate, a CA states that a particular public key belongs to a particular entity, whereas that entity is identified by a given name. Depending on the application’s security and privacy requirements, a security token may include very specific information. In the web services world, web service endpoints can express message security requirements (using WS-SecurityPolicy).
Example: A web service may require that an incoming message must prove a set of claims, e.g. the message must be signed with a security token issued by a specified token issuer. Messages that do not comply with this requirement will be ignored by the service. In order to comply with that requirement, the message sender may have to retrieve a sufficient security token from a token issuer.
The WS-Trust specification defines a web services based interface for requesting, issuing, renewing and validating arbitrary security tokens. WS-Trust calls such issuers ‘security token services’ (STS). In most real world cases, a client will send a SecurityTokenRequest message to an STS, along with certain security claims and a proof of possession, and then expect that the STS sends back another security token that contains the desired claims. Such exchanges can be done multiple times with different security token services. Each of these services receives a set of claims, validates these claims and issues a new security token for the client. Simply speaking, a WS-Trust STS can be seen as a token translator, translating one type of information into another one. An STS may also act as a proxy for token requests or validation operations. For instance, an STS may query another STS if it cannot perform a validation on itself.
WS-Federation
The WS-Federation specification introduces mechanisms to manage and broker trust relationships in heterogeneous and federated environments. This includes support for federated identities, attributes and pseudonyms. ‘Federation’ refers to the concept that two or more security domains agree to interact with each other, specifically letting users of the other security domain access services in the own security domain. For instance, two companies that have a collaboration agreement may decide that employees from the other company may invoke specific web services. These scenarios with access across security boundaries are called ‘federated environments’ or ‘federations’. Each security domain has its own security token service(s), and each service inside these domains may have individual security policies. WS-Federation uses the WS-Security, WS-SecurityPolicy and WS-Trust specifications to describe patterns and scenarios that allow entities from the one domain to obtain security tokens valid in the other domain, thus subsequently getting access to the services in the other domain.
Example: Michael, an employee of Contoso Ltd. wants to purchase goods at a Fabrikam’s shop web service. The employee privacy policy of Contoso Ltd. does not permit that PII (personal identifiable information) from employees is exposed to an outside partner such as the other company. It also would be an administrative nightmare to make all identities of authorised employees from Contoso available to the shop and to keep that list up to date. Additionally, the employee’s identity inside Contoso will probably be meaningless to the Fabrikam shop, because the shop is in another trust domain.
The solution is to have WS-Trust exchanging existing security tokens into different ones that are understood by the other party:
Figure : WS-Trust/WS-Federation example
The employee’s shopping application sends a SecurityTokenRequest message to Consoto’s STS, requesting a token that will be accepted at Fabrikam (step 1): “I am employee Michael from our IT department and I have to invoke the Fabrikam shop web service at this and that address.” The claim “I am employee Michael” is proved, for instance by signing that request message with the employee’s private key or by attaching a valid Kerberos token from Contoso to the message. After internal checks (such as “Is our employee Michael authorised to buy at Fabrikam’s shop of behalf of Contoso?”), the STS from Contoso sends back a security token to Michael (step 2). That security token may include two things: It must include (a) a security token that Michael can attach to the web services invocation and it may include (b) a proof token for Michael with which he can prove that he possesses the security token. The security token may state that “The entity possessing this or that cryptographic key is an employee of Contoso and may purchase goods on our behalf”. This security token is attached to the shop message (step 3). ‘Attached’ means that the shopping request is signed with the token. The shop’s web service cannot interpret the semantics of the token, and asks the Fabrikam’s STS to validate the token (step 4). The STS from Fabrikam may return a new security token containing information like: “The owner of this or that cryptographic key is employee of one of our gold customers” (step 5). After checking that the message from step 3 is signed with the specified cryptographic key and that the security token from step 5 contains a claim that access is granted, the shop request is executed and the results are sent back to the customer (step 6).
Summary
The security-related web services specifications WS-Security, WS-Trust and WS-Federation introduce a model for passing arbitrary types of security claims and tokens between communicating peers. Many of the existing systems scale very well inside closed corporate environments but, like Kerberos, do not work cross-organisationally and require high management overheads for user management (such as username/password) combinations. Claims-based security enables systems to utilise security tokens that may link the owner of a certain cryptographic key to a certain group, without revealing the identity of the owner itself.
The claims-based security model enhances the conventional methodology by abstracting away the token type and by only defining patterns and semantics for the exchange of arbitrary token types, thus enabling cross-trust boundary scenarios as well as distributed peer-to-peer models that are not possible or are unmanageable with today’s systems.
The claims-based security model eases information security management by distributing responsibility for managing identity information to the relevant parties. In the previous example, we have seen that the company is responsible for managing its own user database (to validate company-internal tokens) and for authenticating other organisations, whereas authenticating or authorising a principal from another organisation is done by that other organisation itself.
14 / 31 |