With the continuous development of Web services, various signs that the Web services will be an extremely important pattern of future application architectures. When the web service is used in the test plan and large-scale production, there is a loosely coupled, unrelated to the language and platform, and the benefits of enterprises across enterprises in the organization, transplification of the network link applications are getting better. Our customers, industry analysts and press have determined the key issues to be solved when web services become mainstream: security. This article is to discuss how to choose and implement a standard security architecture to meet the security needs of real companies.
The key to the web service architecture is to deliver integrated, interoperable solutions. By applying this security model, ensuring the integrity, confidentiality, and security of web services, this is critical for software vendors and their customers. The basic security specifications that will be issued will be introduced include:
WEB service description language for integration, security declaration markup for authentication and authorization, for channel confidential security slot (SSL), used for highly confidential XML encryption standards and XML digital signatures for advanced authorization . In addition, several other specifications will also be introduced, including:
Web service security specification (including XML-encryption and XML-digital signatures), XML key management specification, and licensed access control tag language specification, etc.
The model for providing security features and components for Web services requires integration of existing processes and technologies with the security needs of future applications. Unified security technology must abstract the application from a particular mechanism to a particular mechanism. The purpose is to allow developers to easily use heterogeneous systems to establish interoperable security solutions. Successful Web service security methods require a set of flexible, interoperable basic elements, through strategies and configuration, which can make multiple security solutions a feasible solution. Viable web service security mechanisms need to meet and include the following components:
Network security
Support for secure transmission mechanisms such as SSL and other providing confidentiality and integrity.
XML message security
1) XML digital signature so that the recipient can prove the identity of the message sender.
2) XML encryption, the confidentiality of the data element is provided to verify the exchange. W3C releases a memo of XML Key Management Services (XKMS) to help distribute and manage keys required to secure communication between endpoints.
Endpoint verification and authorization
1) Which employees can be used to support which employees can be used in the contract of exchange information to be exchanged between enterprises. The intermediate body is responsible for audit and service original proven.
2) Support, trusted third-party verification services inside the network, such as Kerberos.
Security service description
1) Describe whether digital signature, encryption, authentication, and authorization are supported and how to support them. Web Services requesters use the security element description to find a service endpoint that meets policy requirements and security methods.
2) Oasis set up a technical committee to define authorization and authentication assertions, referred to as SAML, help endpoint acceptance and decision access control.
3) OASIS also established another technical committee to standardize the expression of Extensible Access Control Markup Language, referred to as Xacml, which helps endpoints to resolve SAML assertions in a consistent manner.
XML-related standards bodies "Organization for the Advancement of Structured Information Standards (OASIS)" to join the company set up to develop Web services security standard "Web Services Security (WS-Security)" Technical Committee "Web Services Security Technical Committee (WS-Security TC). This is announced on July 23, 2002. The purpose of the WS-Security standard is to ensure that the Web service application software handles the integrity and confidentiality of the data, which specifies the extension of the Web service protocol SOAP and the message header. This is developed by IBM, Microsoft and VeriSign. WS-Security integrates a variety of security patterns, structures, and techniques, is one of the standard specifications for Web services. Various systems can ensure compatibility with each other through platforms and non-dependent languages.
WS-Security describes the enhancement of SOAP messaging through message integrity, message confidentiality, and separate message authentication. These mechanisms can be used to provide a variety of security models and encryption techniques. WS-Security also provides a general mechanism for associated security tokens and messages. WS-Security does not require a specific type of security token. It is designed to scale (eg, supporting multi-security token formats). For example, a client may provide identity prove to proof of specific business certification.
In addition, WS-Security also describes how to encode binary security token. This specification specifically describes how to encrypt X.509 certificates and Kerberos tickets and how to add an encryption key that is difficult to understand. It also includes a scalability mechanism that can be used to further describe the credential features included in the message.
WS-Security is flexible and it is designed to build a variety of security models (including PKI, Kerberos, and SSL). WS-Security provides support for multi-security tokens, multi-trust domains, multi-signature formats, and multiple encryption technologies. The standard provides three main mechanisms: security token propagation, message integrity, and message confidentiality. These mechanisms themselves do not provide a complete safety solution. In contrast, WS-Security is a component that can be combined with other web services extensions and more advanced applications to accommodate a variety of security models and encryption techniques. These mechanisms can be used independently (eg, transmitting security tokens), or use in a tightly integrated manner (for example, a security token hierarchy associated with a message for signature and encrypted key) .
1, WS-Security and related specifications
Here is a standard-based architecture that meets the Web service security required for real companies. IBM, Microsoft and Verisign teamed up to develop plans and guides for Web service security to develop a group of specifications that provide security Web service security. This security model sets different security technologies, such as public key infrastructure, Kerberos, etc. to ensure security Web services can be built in an existing system environment. By using the natural scalability at the core of the web service model, these specifications are based on some basic technology, such as SOAP, WSDL, XML digital signature, XML encryption, XML encryption, and SSL technology. This allows Web service providers and requestors to develop solutions to individual security requirements that meet their application. This is a WS-Security specification defined by IBM, Microsoft, and VeriSign, which is used to protect the core tools of messages integrity and confidentiality, and mechanisms for associating the statements related to security.
Currently, SSL, TRANSPORT LAYER Security (TLS) and IPsec are used to provide transport level security for web service applications. The security features include authentication, data integrity, and data confidentiality, guarantee point-to-point Web service security. The Web Services application is a multi-hop topology that depends on the message processing interbard forwarding message. When the intermediate body other than the transport layer receives and forwards data, the integrity of the data and any security information of data flow may be lost. Therefore, a comprehensive Web service security architecture must be a mechanism for providing end-to-end security. Figure 1 shows the proposed web service security specification combination.
Figure 1 Web Service Security Specification Combination
This set of specification is built on the SOAP standard specification, including a WS-Security message security model, a WS-Policy, a WS-TRUST trust model, and a privacy model WS-Privacy. Based on these specifications, secure, interoperable web services can be created across multiple trust domains, as well as subsequent specifications, such as security sessions, WS-SecureconVersation, joint trust WS-Federation and Authorize WS-Authorization. Safety specification, related activities, and interoperability profiles together, will facilitate developers to establish interoperable, secure web services. The following is a brief description of the proposed specifications:
WS-Security
Describe how to attach a signature and encrypted header to the SOAP message, which describes how to attach a security token to a message, such as a binary security token X.509 certificate and Kerberos bill. A general mechanism is provided to associate an extensible security token with a message. Using the XML Signature and Security Token ensures the integrity of the message, the message is not modified during the transfer process. Similarly, using an XML encryption and security token can make SOAP messages to secure, provide message confidentiality.
WS-Policy
Describe the capabilities and limits of security strategies on intermediate body and endpoints, such as the required security token, supported encryption algorithm and privacy rules. This is scalable and does not limit the type of requirements and capabilities that can be described. This specification identifies several basic service properties, including privacy attributes, encoding formats, security token requirements, and supported algorithms.
WS-TRUST
A framework describing a trust model that enables web services to securely interoperate. This specification describes how to use the creation of security token guarantee services to use existing direct trust relationships as the basis of the agency trust.
These security token guarantees that services are built on WS-Security, and those necessary security tokens are transmitted in a way that guarantees the integrity and confidentiality of tokens.
WS-privacy
Description Web service providers and requestors declare the model of the subject privacy preferences and organizational privacy practices. By using the combination of WS-Policy, WS-Security and WS-Trust, business organizations can declare and point out the privacy strategy of complying with the declaration. This specification describes how to embed the privacy language into WS-Policy, and how to use WS-Security to associate the privacy declaration with the status of the message, which also describes how to use the WS-TRUST mechanism, while for the user's preference And organize practice statements to evaluate these privacy statements.
WS-SecureConversation
Describe how to manage and authenticate messaging between the parties, including security context exchange, and establish and derive session keys.
WS-Federation
Describe how to manage and trust in an environmentally friendly environment, including support for joint identity. This specification defines how to build a joint trust case using WS-Security, WS-Policy, WS-TRUST, and WS-SecureconVersation, such as how to join Kerberos and PKI infrastructure.
WS-Authorization
Describe how to manage authorization data and authorization policies, how to specify declarations within security tokens, and how these statements are explained at the endpoint. This specification is flexible and scalable in licensed formats and authorized languages.
Since this Web service security model is compatible with existing security models for authentication, data integrity, and data confidentiality today, it can integrate web-based solutions with existing security models. stand up. For example, prior art, such as SSL provides simple point-to-point integrity and confidentiality for messages, and web service security models support these existing secure transmission mechanisms to integrate with WS-Security and other specification to provide across multiple inter medium signs and The end-to-end integrity and confidentiality of the transfer protocol. The Public Key Infrastructure (PKI) model relates to a certificate authority that is issued with a public symmetrical key and a mechanism that declares an attribute except the key ownership. The owner of this certificate can use the associated key to represent a variety of declarations. In addition, the Kerberos model relies on the Key Distribution Center to proxy between all parties by issuing encrypted symmetrical keys. Web Services Security Model Support Security Token Services uses a public asymmetric key to issue security tokens. Existing trust models are usually based on an organization, such as a Web Services of the UDDI Business Registration Center. UDDI has multiple participants, and its trust model is not based on the requirements of a particular authentication mechanism to define a separate model for trust, but give the authentication responsibility to the information administrator of each node. Web services in each UDDI may have their own authentication mechanisms and enforce their own access control policies, and trust depends on the trust between service requesters and operators who manage their information.
2, Web service reliability and SOAP layer security extension
Leading IT vendors such as Fujitsu, Hitachi, NEC, Oracle, Sonic Software, and Sun, announced that they will work together to publish Web Services Reliability technical specifications. This WS-Reliability technical specification will provide a more reliable transmission infrastructure, speeding up the use of Web services to adapt to a variety of application needs of the business community.
WS-Reliability is a technical specification for open, reliable web service messages, including guarantee submit, copy information exclusion, and message classification, etc., allowing more reliable messages between various web services. WS-Reliability is based on the SOAP protocol, not limited to the basic transmission protocol.
Since the SOAP specification has been widely concerned about the security mechanisms such as encryption, certification and authorization of SOAP standards since 2001. These three aspects are important for any B2B, but the SOAP standard does not have much consideration of SOAP security requirements when developing specifications. Because SOAP a very important design goal is its simplicity, as much as possible to achieve the corresponding functionality as much as possible.
SOAP security solutions are implemented based on three W3C XML specifications: XML Digital Signature, XML Encryption, and XML Key Management Services. SOAP layer is safe onto the transport layer and the application layer, and the security of the SOAP layer is expanded, and five basic requirements for security are applied to the entire SOAP information, including SOAP heads, and SOAP. At the same time, more security measures can also be solved together in conjunction with the SOAP layer safety and transportation layers and applications. (As shown in Figure 2 below)
Figure 2 Soap layer security extension
1) SOAP security extension: Digital Signature (SIGNATURE)
"SOAP SECURITY EXTENSIONS: DIGITAL SIGITAL SIGITAL" is initially imagined to extend SOAP using XML Digital Signature Syntax [XML Digital Signature Syntax ", defining signature properties in the head element of SOAP (
2) Security token - Define security tokens represent information related to security (for example, X.509 certificates, Kerberos bills, certificates, mobile device security tokens from SIM cards, username and many more). The SOAP specification defines the use of XML Signature in the head element of SOAP 1.1. The value after the digital signature calculated by the encryption algorithm is attached to the data object, and the data acceptance object can verify the source and integrity of the data in the signature. The encrypted transmission information avoids the deception of the data recipient by counterfeiting information. Although the digital signature provides these security services: the certificate of information source - the acceptor of the information can determine the identity of the sender of this information; the integrity of information --- Information recipient can determine that this information is not issued ;; Inequality - any party in things can not deny his behavior afterwards. However: Digital signatures do not provide information authentication, malicious destroyers can record an information and repeatedly send (repeated attacks), in order to avoid this type of attack, digital signatures must combine a certain way to ensure uniqueness of information, such as: time Time Stamps or Nonces et al. The date and time of the signature are attached to the message and sign with the message. Adding this information can be added to the extension element. When the digital signature is used to verify the signage of the sender, the sender must provide a private key and so on. SOAP information can also use other security technology, more SOAP security specifications are constantly improving, with SOAP security enhancement, SOAP technology will get more and more extensive applications.
3) UDDI Security: Identification and Authorization
The key principle of publishing APIs using UDDI is to allow only authorized users to publish or modify data in the UDDI Business Registration Center. Each distributed UDDI Business Registration Center Maintains - Zhang Wei - the authorized user list and tracks the BusinessSentity or TMODEL data created by all users. Only the creator of information allows you to change or delete this information.
Each UDDI Business Registration Center is called an Operator Site, and the operating portal is allowed to define his own user authorization mechanism, but all the public UDDI registration centers for all signing agreements need to be satisfied. The minimum security specification defined in the agreement is specified to provide similar security mechanisms.
