Authentication
Authentication involves comparing provided identity information (a "challenge") to something already stored about this individual. Authentication is classically divided into three types: something you know, something you have, or something you are:
· Something you know—Pin, password, pass phrase, shared secret
· Something you have—Key, card, token
· Something you are—Biometrics such as fingerprint, retinal scan, voice print, palm print
Single-factor authentication (using just one of the preceding types) is the simplest but is not very strong. Stealing or guessing a password is easy, and the rightful individual has no way to refute this is the case. Furthermore, because a password is something you know, you can tell it to someone or she can guess it, and with no other factor checked, that person is into the system with nothing stopping her.
Two-factor authentication, also known as strong authentication, is much stronger and is considered the standard when authentication is for anything of high value. Either something you have or something you are is added to the something you know category of shared secret. Something you have is typically a card, token, or device of some sort. Something you are is a biometric such as a fingerprint, retinal scan, or voice print. Outside military applications, authentication stronger than two-factor is rarely found. To strengthen two-factor authentication, you must strengthen the process used to create the individual factors.
How rigorous the authentication needs to be and what types of factors should be used in the one-, two-, or more factors of authentication require that you think about the level of trust needed. What is it that you are trying to protect? If the Web service is one that integrates vendors into your supply chain, and they have no access to critical corporate or customer data, the level of authentication may be lower than for a Web service that integrates an employer to its 401k provider and represents an employee requesting fund reallocation.
Authorization
Authorization is the process of establishing what someone who has been authenticated is allowed to do. The entity receiving the request for service will be granting permissions for each identity to access certain items.
Most Web services coming in over the public network to an enterprise require authentication; it is not usually acceptable to provide services that you expect to be paid for without knowing who is using them. So fundamentally, authorization requires authentication. Additionally, Web services frequently expose vital business data to the requestor, who must be identified and not remain anonymous. Exceptions to this rule are free services that do not care who use them. If a service provides different levels of access depending on who is using it, that service also requires authorization to determine, based on identity, what services are accessible to whom.
One way that authorization is implemented is through a set of credentials that a subject identity carries and presents; those credentials are then mapped into access to certain restricted items. Alternatively, rights can be attached to restricted content, and these rights are mapped to identities and the permissions they will be granted to this content.
On the HTML-based Web, authorization has typically been very coarse grained and either gives access to entire sections of a Web site or denies access completely. With Web services, on the other hand, very fine-grained control specifying access to messages, parts of messages, or content carried by a message is possible. Unlike many security concepts, authorization is actually very easy to understand, but it turns out to be exceedingly complex technologically as well as socially. You will see why in Chapter 6, "Portable Identify, Authentication, and Authorization," which discusses standards such as SAML that are involved with this aspect of identity.
Integrity
Integrity is an assertion that no one has tampered with a message since it was initially created. This assures the sender and the receiver that every bit produced by the sender is received by the recipient in precisely unaltered form. In cryptographic terms, data integrity is accomplished by using digital signatures. Messages in which data integrity is required (Footnote 7) must explicitly or implicitly include the identity and credentials of the sender to enable this kind of message-level security. Why? Because proving integrity means proving no bits have been changed in the message, which involves sending something with the message that no one in the middle could fraudulently create. That, in turn, requires signing that data with a key that only the sender could have had (more on this in Chapter 4, "Safeguarding the Identity and Integrity of XML Messages"). Message integrity- and identity-related issues (authentication and authorization) are often inter-related. Ironically, no matter how sophisticated your security technology becomes, the core security issue comes down to this: Do you know whom you are dealing with and do you trust those people?
Confidentiality
Confidentiality is keeping the message secret. This process requires encryption, which scrambles the message in such a way that only authorized identities can decrypt and see the data. To do this, you exchange a shared secret and an algorithm for encrypting and decrypting the message. You could imagine Bob and Alice agreeing that they were going to encrypt their messages to each other by adding some number to each letter in the alphabet (the algorithm) and that number would be 2 for the next five days (the key). Thus, the message from Bob to
With typical contemporary encryption strategies, you provide the algorithm openly and rely on the strength of the key to keep the encryption secure. The trick is keeping the key secret. You could keep the key secret by giving it to the recipients in some way outside the message exchange, such as mailing it to them or phoning them. However, this approach doesn't scale up very well to large numbers of participants, so exchanging this key usually requires Public Key Infrastructure (PKI) technology, which is designed to manage and exchange keys. Chapter 3, "The Foundations of Distributed Message-Level Security," describes PKI in more detail, and Chapter 5, "Ensuring Confidentiality of XML Messages," goes into a lot of detail about encryption, specifically XML Encryption.
Non-repudiation
As digital transactions are used in more and more legal contracts and as the acceptability of digital signatures becomes commonplace, the legal aspects of identity will become critical for Web services. First and foremost among those legal aspects of identity is non-repudiation.
Non-repudiation proves that one identity sent the data only to another identity. This then proves that this specific transaction was entered into by the recipient, and neither party can refute or deny that it occurred later. If the transaction is challenged legally, a contract that was supposedly executed must be shown to have been entered into by both parties. Each party must have seen the contract as signed, and their identities—confirmed traditionally by validating "wet" signatures on paper and notary witnesses—must have been confirmed at the time of signing. These are difficult, and as yet legally unchallenged, tenants to uphold in a digital and anonymous world, but that day is coming.
Non-repudiation depends on public key cryptography technology. You prove that one identity sent the data only to another identity because the sender used the recipient's public key, and it is only the recipient with his secret private key who can decrypt the data. To achieve legal non-repudiation, more is needed, such as a separate time-and-date-stamp notary to prove when the transaction occurred as well as independent verification of the participants' identities.
Building on the brief introduction to Web services and information security, you can now delve into Web services security basics. A basic tenet of Web services security is that no new security technologies were invented. Instead, you will build on established security technologies and purpose them to your message-level security needs.
XML Signature
XML Signature is foundational technology for the standard called WS-Security, covered in detail in Chapter 7, and for Web services security in general. XML Signature is built on top of mature digital signature technology. The purpose of digital signatures is to provide a mechanism for message integrity (no one has changed the message since it was created) and non-repudiation (you cannot refute that this message exchange occurred). XML Signature enables you to encode digital signatures into XML.
Electronic signatures were approved by Congress in June 2000. This approval gives legitimacy to electronic signatures and prevents the contesting of a signed contract solely because it is signed electronically. This event set the stage for digital signature standards. The genesis of XML Signature was a joint IETF/W3C working group called XML-DSig that was established to create a highly extensible signature syntax tightly integrated with existing XML technologies, but one that could also handle composite documents from diverse application domains as well. The XML-Signature Syntax and Processing W3C Recommendation defines the XML Signature syntax and associated processing rules. Its ancestors include PKCS#7 Signature and S/MIME. PKCS#7 is part of Public Key Cryptography Standards (PKCS) created by RSA Data Security. With this standard, someone could sign XML, but not in a way consistent with standardized XML format. And it was not possible to sign just part of an XML document as it is with XML Signature. Secure Multipurpose Internet Mail Extensions (S/MIME) already provided a way to bind a digital signature to an email message in a way that allowed the recipient to verify both integrity and non-repudiation of the signer.
XML Signature is a core foundation for Web services security. It was the first XML security standard to reach recommendation status. It is core to WS-Security, XKMS, and other Web services security standards you will be learning much more about. It will be core to your being able to provide integrity and non-repudiation, and you will also find it to be invaluable in the process of transporting shared secret keys that are needed by XML Encryption.
XML Encryption
Like XML Signature, XML Encryption is built on top of mature cryptographic technology—in this case, shared key encryption technology. Core requirements for XML Encryption are that it must be able to encrypt an arbitrarily sized XML message, and it must do so efficiently. Those two factors led its creators to choose shared key (symmetric) encryption as the foundation for XML Encryption. Encryption provides for message confidentiality (the message will be secret from all but the intended recipient). The reason XML Encryption is needed over and above transport-level encryption such as SSL is that you need to maintain confidentiality of messages in the face of the message taking multiple hops on its way to its destination. This will be common when shared services are utilized. You also need confidentiality when the XML message is stored even after it reaches its final destination. This requirement is called persistent confidentiality.
Like XML Signature, XML Encryption applies standard algorithms to data and then stores that encrypted result in XML. And as with XML Signature, you can apply encryption selectively only to portions of a document.
XML Encryption builds on and shares several concepts with XML Signature. Like XML Signature, it is a W3C Recommendation. It is a vitally important second foundation to Web services security because it is the way you will achieve confidentiality in your XML messages. Remember, the key benefit XML Encryption brings over any other encryption strategy is that it allows confidentiality to be satisfied across more than just the context of a single SOAP request.
SAML
The purpose of SAML is to allow trust assertions to be specified in XML. Assertions apply to an individual or an entity and are "attached" to a message and go where it goes, leading to the simple description of SAML as enabling "portable trust." SAML assertions take the form of authentications, authorizations, or attributes of entities. Assertions can be claims, statements, or declarations. Assertions are accepted as true only in the context of the integrity and authenticity of the entity making the assertions. At this point, the situation becomes really complicated: Everything you are counting on depends on third parties; you have to trust them to trust the individual on whose behalf claims and assertions are being made.
SAML defines a set of Web APIs (that is, Web services) to be used to obtain these assertions from trust services that make authorization and authentication decisions about individuals and entities. After the SAML authority has made its assertions, SAML also provides a way to exchange this information with other systems. As you will see, WS-Security is enabled to use SAML as one of its security tokens applied to a SOAP message. You will also look at a large project called Project Liberty that is setting out to use SAML (and actually extend it) assertions across multiple security domains, allowing single sign-on to a circle of trust established between business partners.
SAML came from a blending of the two early standards efforts around portable trust called S2ML and AuthML. SAML is developed through the Organization for the Advancement of Structured Information Standards (OASIS) XML-based Security Services Technical Committee (SSTC). SAML 1.0 was approved as a standard in November 2002, version 1.1 was approved as an OASIS standard in August 2003, and a working group is already discussing v2.0.
WS-Security
XML Signature and XML Encryption are about XML security. So what is WS-Security about? It is about SOAP security.
WS-Security is an overarching conceptual model that abstracts different security technologies into "claims" and "tokens." Ways to package security tokens into SOAP messages are the nuts and bolts of WS-Security. The broader context of WS-Security is a set of additional road-map specifications built on these concepts and solidified into XML specifications. They involve how to apply for a security token, how tokens are linked to identity, how they are linked to a Web service, and more.
Microsoft initially released WS-Security in October 2001. In April 2002, IBM and VeriSign joined Microsoft in releasing their joint document called "Security in a Web Services World." This initial security framework was submitted to OASIS in June 2002. OASIS formed the Web Services Security (WSS) technical committee in September 2002 to standardize this specification. Most platform and tools vendors will have shipped support for the initial WS-Security draft specification by early 2004. The WS-Security specification reached "committee draft" status in January 2004.
WS-Security provides a mechanism that allows you to digitally sign (using XML Signature) all or part of a SOAP message and pass the signature in the SOAP header. It provides a mechanism that allows you to encrypt (using XML Encryption) all or part of a SOAP message. It also provides a way to pass information in a SOAP header about the encryption keys needed to decrypt the message or verify the digital signature. And it allows trust assertions about the SOAP message to be passed in the SOAP header as well. A variety of bindings for security tokens have been defined. All these tokens will be explained in detail later.
Trust Issues
WS-Policy allows organizations exposing Web services to specify the specific requirements of their Web services for such issues as privacy or security. WS-Policy is a high-level specification providing the basic constructs needed to compose a particular policy language (such as WS-SecurityPolicy). Closely related to WS-Policy is WS-PolicyAssertions, which provides some basic policy assertions that would apply to any type of policy (for example, the Language assertion), and WS-PolicyAttachment, which gives guidance on how to attach a policy to a resource (for example, a WSDL). WS-SecurityPolicy is a specific type of policy using the WS-Policy framework that answers certain security requirement and configuration questions for a Web service, such as What encryption algorithms are supported? What parameters must be encrypted? What types of security tokens are understood?
Other WS-Security–Related Specs
No comments:
Post a Comment