Web Services Security Policy Language (WS-SecurityPolicy)
July 2005
Version 1.1
Authors
Giovanni Della-Libera, Microsoft
Martin Gudgin, Microsoft
Phillip Hallam-Baker, VeriSign
Maryann Hondo, IBM
Hans Granqvist, Verisign
Chris Kaler, Microsoft (editor)
Hiroshi Maruyama, IBM
Michael McIntosh, IBM
Anthony Nadalin, IBM (editor)
Nataraj Nagaratnam, IBM
Rob Philpott, RSA Security
Hemma Prafullchandra, VeriSign
John Shewchuk, Microsoft
Doug Walter, Microsoft
Riaz Zolfonoon, RSA Security
Copyright Notice
(c) 2001-2005 International Business Machines Corporation, Microsoft Corporation, RSA Security Inc., and VeriSign Inc. All rights reserved. Permission to copy and display the WS-SecurityPolicy Specification (the “Specification”, which includes WSDL and schema documents), in any medium without fee or royalty is hereby granted, provided that you include the following on ALL copies of the Specification, that you make:
1. A link or URL to the Specification at one of the Authors’ websites
2. The copyright notice as shown in the Specification.
IBM, Microsoft, RSA and Verisign (collectively, the "Authors") each agree to grant you a license, under royalty-free and otherwise reasonable, non-discriminatory terms and conditions, to their respective essential patent claims that they deem necessary to implement the Specification.
THE SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION
OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE SPECIFICATION.
The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the Specification will at all times remain with the Authors.
No other rights are granted by implication, estoppel or otherwise.
Abstract
This document indicates the policy assertions for use with WS-Policy which apply to WSS: SOAP Message Security, WS-Trust and WS-SecureConversation. Composable Architecture
By using the XML, SOAP and WSDL extensibility models, the WS* specifications are designed to be composed with each other to provide a rich Web services environment. WS-SecurityPolicy by itself does not provide a complete security solution for Web services. WS-SecurityPolicy is a building block that is used in conjunction with other Web service and application-specific protocols to accommodate a wide variety of security models.
Status
This is a public consultation draft release of this specification for community evaluation and review. Feedback on this specification is handled through the WS-* Workshop process.
Table of Contents
1. Introduction
1.1 Example
2. Terminology and Notation
2.1 Terminology
2.2 Namespaces
2.3 Notational Conventions
2.4 Schema Files
2.5 Compliance
3. Security Policy Model
3.1 Security Assertion Model
3.2 Nested Policy Assertions
3.3 Security Binding Abstraction
4. Policy Considerations
4.1 Nested Policy
4.1.1 Nesting Policy Elements
4.1.2 Nested Policy Assertions
4.1.3 Nesting Policy Processing Rules
4.1.4 Nested Policy Normalization Worked Example
4.1.5 Nested Policy Intersection Worked Example
4.2 Policy Subjects
5. Protection Assertions
5.1 Integrity Assertions
5.1.1 SignedParts Assertion
5.1.2 SignedElements Assertion
5.2 Confidentiality Assertions
5.2.1 EncryptedParts Assertion
5.2.2 EncryptedElements Assertion
5.3 Required Elements Assertion
5.3.1 RequiredElements Assertion
6. Token Assertions
6.1 Token Inclusion
6.1.1 Token Inclusion Values
6.2 Token Properties
6.2.1 [Derived Keys] Property
6.3 Token Assertions
6.3.1 UsernameToken Assertion
6.3.2 IssuedToken Assertion
6.3.3 X509Token Assertion
6.3.4 KerberosToken Assertion
6.3.5 SpnegoContextToken Assertion
6.3.6 SecurityContextToken Assertion
6.3.7 SecureConversationToken Assertion
6.3.8 SamlToken Assertion
6.3.9 RelToken Assertion
6.3.10 HttpsToken Assertion
7. Security Binding Properties
7.1 [Algorithm Suite] Property
7.2 [Timestamp] Property
7.3 [Protection Order] Property
7.4 [Signature Protection] Property
7.5 [Token Protection] Property
7.6 [Entire Header and Body Signatures] Property
7.7 [Security Header Layout] Property
7.7.1 Strict Layout Rules
8. Security Binding Assertions
8.1 AlgorithmSuite Assertion
8.2 Layout Assertion
8.3 TransportBinding Assertion
8.4 SymmetricBinding Assertion
8.5 AsymmetricBinding Assertion
9. Supporting Tokens
9.1 SupportingTokens Assertion
9.2 SignedSupportingTokens Assertion
9.3 EndorsingSupportingTokens Assertion
9.4 SignedEndorsingSupportingTokens Assertion
9.5 Example
10. WSS: SOAP Message Security Options
10.1 Wss10 Assertion
10.2 Wss11 Assertion
11. WS-Trust Options
11.1 Trust10 Assertion
12. Security Considerations
13. Acknowledgements
14. References
Appendix A - Assertions and WS-PolicyAttachment
A.1 Endpoint Policy Subject Assertions
A.1.1 Security Binding Assertions
A.1.3 Token Assertions
A.1.4 WSS: SOAP Message Security 1.0 Assertions
A.1.5 WSS: SOAP Message Security 1.1 Assertions
A.1.6 Trust 1.0 Assertions
A.2 Operation Policy Subject Assertions
A.2.1 Supporting Token Assertions
A.3 Message Policy Subject Assertions
A.3.1 Supporting Token Assertions
A.3.2 Protection Assertions
A.4 Assertions With Undefined Policy Subject
A.4.1 General Assertions
A.4.2 Token Usage Assertions
A.4.3 Token Assertions
A.4.4 WSS: SOAP Message Security 1.0 Assertions
A.4.5 WSS: SOAP Message Security 1.1 Assertions
A.4.6 Trust 1.0 Assertions
Appendix B – Issued Token Policy
Appendix C – Strict Security Header Layout Examples
C.1 Transport Binding
C.1.1 Policy
C.1.2 Initiator to Recipient Messages
C.1.3 Recipient to Initiator Messages
C.2 Symmetric Binding
C.2.1 Policy
C.2.2 Initiator to Recipient Messages
C.2.3 Recipient to Initiator Messages
C.3 Asymmetric Binding
C.3.1 Policy
C.3.2 Initiator to Recipient Messages
C.3.3 Recipient to Initiator Messages
1. Introduction
WS-Policy defines a framework for allowing web services to express their constraints and requirements. Such constraints and requirements are expressed as policy assertions. This document defines a set of security policy assertions for use with the WS-Policy framework with respect to security features provided in WSS: SOAP Message Security, WS-Trust and WS-SecureConversation. This document takes the approach of defining a base set of assertions that describe how messages are to be secured. Flexibility with respect to token types, cryptographic algorithms and mechanisms used, including using transport level security is part of the design and allows for evolution over time. The intent is to provide enough information for compatibility and interoperability to be determined by web service participants along with all information necessary to actually enable a participant to engage in a secure exchange of messages.
Sections 3.4, 11, 12, all examples and all Appendices are non-normative.
1.1 Example
Table 1 shows an "Effective Policy" example, including binding assertions and associated property assertions, token assertions and integrity and confidentiality assertions.
Table 1: Example security policy.
(01)
(02)
(03)
(04)
(05)
(06) sp:IncludeToken=".../IncludeToken/Once" /> (07) (08) (09) (10) (11) (12) (13) (14) (15) Namespace="https://www.doczj.com/doc/cf11842118.html,/ws/2004/08/addressing" /> (16) (17) (18) (19) (20) Line 1 in Table 1 indicates that this is a policy statement and that all assertions contained by the wsp:Policy element are required to be satisfied. Line 2 indicates the kind of security binding in force. Line 3 indicates a nested wsp:Policy element which contains assertions that qualify the behavior of the SymmetricBinding assertion. Line 4 indicates a ProtectionToken assertion. Line 5 indicates a nested wsp:Policy element which contains assertions indicating the type of token to be used for the ProtectionToken. Line 6 indicates that a Kerberos V5 APREQ token is to be used by both parties in a message exchange for protection. Line 9 indicates that signatures are generated over plaintext rather than ciphertext. Line 10 indicates that the signature over the signed messages parts is required to be encrypted. Lines 13-16 indicate which message parts are to be covered by the primary signature; in this case the soap:Body element, indicated by Line 14 and any SOAP headers in the WS-Addressing namespace, indicated by line 15. Lines 17-19 indicate which message parts are to be encrypted; in this case just the soap:Body element, indicated by Line 18. 2. Terminology and Notation 2.1 Terminology Policy A collection of policy alternatives. Policy Alternative A collection of policy assertions. Policy Assertion An individual requirement, capability, other property, or a behavior. Initiator The role sending the initial message in a message exchange. Recipient The targeted role to process the initial message in a message exchange. Security Binding A set of properties that together provide enough information to secure a given message exchange. Security Binding Property A particular aspect of securing an exchange of messages. Security Binding Assertion A policy assertion that identifies the type of security binding being used to secure an exchange of messages. Security Binding Property Assertion A policy assertion that specifies a particular value for a particular aspect of securing an exchange of message. Assertion Parameter An element of variability within a policy assertion. Token Assertion Describes a token requirement. Token assertions defined within a security binding are used to satisfy protection requirements. Supporting Token A token used to provide additional claims. 2.2 Namespaces The XML namespace URI that MUST be used by implementations of this specification is: https://www.doczj.com/doc/cf11842118.html,/ws/2005/07/securitypolicy Table 2 lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant. Table 2: Prefixes and XML Namespaces used in this specification. Prefix Namespace Specification(s) S https://www.doczj.com/doc/cf11842118.html,/soap/envelope/[SOAP11] ds https://www.doczj.com/doc/cf11842118.html,/2000/09/xmldsig#[XMLDSIG] enc https://www.doczj.com/doc/cf11842118.html,/2001/04/xmlenc#[XMLENC] [WSS10] wsu https://www.doczj.com/doc/cf11842118.html,/wss/2004/01/oasis-200401- wss-wssecurity-utility-1.0.xsd wsse https://www.doczj.com/doc/cf11842118.html,/wss/2004/01/oasis-200401- [WSS10] wss-wssecurity-secext-1.0.xsd [WSS11] wsse11 https://www.doczj.com/doc/cf11842118.html,/wss/2005/xx/oasis-2005xx- wss-wssecurity-secext-1.1.xsd wsp https://www.doczj.com/doc/cf11842118.html,/ws/2004/09/policy[WS-Policy], [WS- PolicyAttachment] xsd https://www.doczj.com/doc/cf11842118.html,/2001/XMLSchema [XMLSchema Part1], [XMLSchema Part2] wst https://www.doczj.com/doc/cf11842118.html,/ws/2005/02/trust [WS-Trust] wsc https://www.doczj.com/doc/cf11842118.html,/ws/2005/02/sc[WS- SecureConversation] wsa https://www.doczj.com/doc/cf11842118.html,/ws/2004/08/addressing [WS-Addressing] sp https://www.doczj.com/doc/cf11842118.html,/ws/2005/07/securitypolicy This specification 2.3 Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. This specification uses the following syntax to define outlines for messages: ?The syntax appears as an XML instance, but values in italics indicate data types instead of literal values. ?Characters are appended to elements and attributes to indicate cardinality: o"?" (0 or 1) o"*" (0 or more) o"+" (1 or more) ?The character "|" is used to indicate a choice between alternatives. ?The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice. ?The characters "[" and "]" are used to call out references and property names. ?Ellipses (i.e., "...") indicate points of extensibility. Additional children and/or attributes MAY be added at the indicated extension points but MUST NOT contradict the semantics of the parent and/or owner, respectively. By default, if a receiver does not recognize an extension, the receiver SHOULD ignore the extension; exceptions to this processing rule, if any, are clearly indicated below. ?XML namespace prefixes (see Table 2) are used to indicate the namespace of the element being defined. In this document reference is made to the wsu:Id attribute and the wsu:Created and wsu:Expires elements in a utility schema (http://docs.oasis- https://www.doczj.com/doc/cf11842118.html,/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd). The wsu:Id attribute and the wsu:Created and wsu:Expires elements were added to the utility schema with the intent that other specifications requiring such an ID or timestamp could reference it (as is done here). WS-SecurityPolicy is designed to work with the general Web Services framework including WSDL service descriptions, UDDI businessServices and bindingTemplates and SOAP message structure and message processing model, and WS-SecurityPolicy should be applicable to any version of SOAP. The current SOAP 1.2 namespace URI is used herein to provide detailed examples, but there is no intention to limit the applicability of this specification to a single version of SOAP. 2.4 Schema Files A normative copy of the XML Schema [XML Schema Part 1, Part 2] description for this specification can be retrieved from the following address: https://www.doczj.com/doc/cf11842118.html,/ws/2005/07/securitypolicy/ws-securitypolicy.xsd 2.5 Compliance Normative text within this specification takes precedence over outlines, which in turn take precedence over the XML Schema [XML Schema Part 1, Part 2], which in turn take precedence over examples. Sections 3.4, 11, 12, and all Appendices are not normative. 3. Security Policy Model This specification defines policy assertions for the security properties for Web services. These assertions are primarily designed to represent the security characteristics defined in the WSS: SOAP Message Security, WS-Trust and WS-SecureConversation specifications, but they can also be used for describing security requirements at a more general or transport-independent level. The primary goal of this specification is to define an initial set of patterns or sets of assertions that represent common ways to describe how messages are secured on a communication path. The intent is to allow flexibility in terms of the tokens, cryptography, and mechanisms used, including leveraging transport security, but to be specific enough to ensure interoperability based on assertion matching. It is a goal of the security policy model to leverage the WS-Policy framework’s intersection algorithm for selecting policy alternatives and the attachment mechanism for associating policy assertions with web service artifacts. Consequently, wherever possible, the security policy assertions do not use parameters or attributes. This enables first-level, QName based assertion matching without security domain-specific knowledge to be done at the framework level. The first level matching is intended to provide a narrowed set of policy alternatives that are shared by the two parties attempting to establish a secure communication path. In general, assertions defined in this specification allow additional attributes, based on schemas, to be added on to the assertion element as an extensibility mechanism but the WS-Policy framework will not match based on these attributes. Attributes specified on the assertion element that are not defined in this specification or in WS-Policy are to be treated as informational properties. 3.1 Security Assertion Model The goal to provide richer semantics for combinations of security constraints and requirements and enable first-level QName matching, is enabled by the assertions defined in this specification being separated into simple patterns: what parts of a message are being secured (Protection Assertions), general aspects or pre-conditions of the security (Conditional Assertions), the security mechanism (Security Binding Assertions) that is used to provide the security, the token types and usage patterns (Supporting Token Assertions) used to provide additional claims, and token referencing and trust options (WSS and Trust Assertions). To indicate the scope of protection, assertions identify message parts that are to be protected in a specific way, such as integrity or confidentiality protection, and are referred to as protection assertions. The general aspects of security includes the relationships between or characteristics of the environment in which security is being applied, such as the tokens being used, which are for integrity or confidentiality protection and which are supporting, the applicable algorithms to use, etc. The security binding assertion is a logical grouping which defines how the general aspects are used to protect the indicated parts. For example, that an asymmetric token is used with a digital signature to provide integrity protection, and that parts are encrypted with a symmetric key which is then encrypted using the public key of the recipient. At its simplest form, the security binding restricts what can be placed in the wsse:Security header and the associated processing rules. The intent of representing characteristics as assertions, is so that QName matching will be sufficient to find common alternatives, and so that many aspects of security can be factored out and re-used. For example, it may be common that the mechanism is constant for an endpoint, but that the parts protected vary by message action. 3.2 Nested Policy Assertions Assertions may be used to further qualify a specific aspect of another assertion. For example, an assertion describing the set of algorithms to use may qualify the specific behavior of a security binding. To enable this set of functionality, this specification introduces a mechanism for nesting policy assertions underneath other assertions. This mechanism is described in Section 4. 3.3 Security Binding Abstraction As previously indicated, individual assertions are designed to be used in multiple combinations. The binding represents common usage patterns for security mechanisms. These Security Binding assertions are used to determine how the security is performed and what to expect in the wsse:Security header. Bindings are described textually and enforced programmatically. This specification defines several bindings but others can be defined and agreed to for interoperability if participating parties support it. A binding defines the following security characteristics: ?The minimum set of tokens that will be used and how they are bound to messages ?Any necessary key transfer mechanisms ?Any required message elements (e.g. timestamps) ?The content and ordering of elements in the wsse:Security header. Elements not specified in the binding are not allowed. ?How correlation of messages is performed securely (if applicable to the message pattern) Together the above pieces of information, along with the assertions describing conditions and scope, provide enough information to secure messages between an initiator and a recipient. The following list identifies the bindings defined in this specification. The bindings are identified primarily by the style of protection encryption used to protect the message exchange. A later section of this document provides details on the assertions for these bindings. ?TransportBinding ?SymmetricBinding ?AsymmetricBinding 4. Policy Considerations The following sections discuss details of WS-Policy and WS-PolicyAttachment relevant to this specification. 4.1 Nested Policy The WS-Policy specification defines a mechanism for describing capabilities and requirements as assertions. These assertions are contained within one of wsp:Policy, wsp:All, or wsp:ExactlyOne. The WS-Policy specification defines the nesting semantics associated with the wsp:Policy, wsp:All and wsp:ExactlyOne. However these semantics do not allow individual assertions to specify that the child elements contained within the assertion should also be evaluated as assertions. The following section is an overview of the nesting semantics of WS-Policy elements. 4.1.1 Nesting Policy Elements To determine whether two assertions are "compatible", the QName value, that is the Name and Namespace of one assertion element is compared to the QName value of another assertion. If they match, then they are compatible. A wsp:Policy element may contain one or more assertions. To determine whether two wsp:Policy elements are "compatible", each assertion in one wsp:Policy element is compared, as described above, to the assertions in another wsp:Policy element. If all assertions from each wsp:Policy element are matched exactly, they are compatible. To enable richer sets of options to be expressed, WS-Policy defines the wsp:All and wsp:ExactlyOne elements. These elements may be placed as immediate children of a wsp:Policy element. In addition, these two elements may also appear under themselves. This allows for a policy to describe alternative options within policy. Let’s say that a policy wishes to express requirements for A and (B or C). This could be described as two policy statements: Alternatively, we can use the wsp:All and wsp:ExactlyOne elements to describe the alternative policy in a single wsp:Policy element: This process is described in more detail in the WS-Policy specification. 4.1.2 Nested Policy Assertions Some assertions may need to declare that additional assertions, scoped only to that assertion, further qualify the behavior and compatibility semantics of that assertion. Whereas the wsp:All and wsp:ExactlyOne elements describe requirements and alternatives of a wsp:Policy element, nested assertions describe requirements and alternatives for the enclosing assertion element. To enable these semantics, this specification defines some assertions such that they have a single wsp:Policy child element which in turn contains assertions which qualify the behavior of the enclosing assertion. Two such assertions are compatible if they have the same QName AND their nested policy expressions (if any) are compatible. For example, let’s say that a policy wishes to express requirements for A and B, and furthermore that B requires C and D. The normalized policy statement would look like: The policy above is fully normalized. Policy normalization DOES NOT promote nested assertions to the outer scope. The wsp:Policy element allows any assertion as content. However, assertions defined in this specification that allow nested policy will typically constrain the content of that nested policy. Note: To enable automatic intersection of nested policy assertions, policy engines will need to be modified to scan the contents of assertions to determine whether intersection is required. This approach is being investigated by the WS-Policy working group to formalize the notion of nested policy and to define processing behavior requirements for nested policy. Additionally, an attribute may be defined to advertise to a policy engine that scanning is required on a particular assertion. For example: ... Ideally the x:ContainsPolicy attribute will, at some point, be moved in the WS-Policy namespace. 4.1.3 Nesting Policy Processing Rules This section provides rules for processing nested policy based on the informal description above; 1.Assertions MUST specify whether or not they contain nested policy. 2.Assertions SHOULD specify which other assertions can be present in their nested policy. 3.Nested assertions need to be specifically designed for nesting inside one or more outer assertions.Assertions SHOULD specify which assertions they can be nested within. 4.Assertions from one domain SHOULD NOT be nested inside assertions from another domain. For example, assertions from a transaction domain should not be nested inside an assertion from a security domain. 5.Assertions containing nested policy are normalized recursively such that in the normal form each nested policy contains no choices. Thus each outer assertion that contains nested policy containing choices is duplicated such that there are as many instances of the outer assertion as there are choices in the nested policy, one instance for each nested choice, recursively. See Section 4.1.4 for a worked example of normalization. 6.Nested policies are intersected in their own processing contexts with the corresponding nested policy in a matching outer assertion. Thus two assertions having nested policy intersect if the outer assertion QName matches and the nested policies intersect. Intersection always occurs using the normalized form. See Section 4.1.5 for a worked example of intersection. 7.An assertion with an empty nested policy does not intersect with the same assertion without nested policy. 4.1.4 Nested Policy Normalization Worked Example This section shows a worked example of normalizing assertions with nested policy. Policy 1 The above policy is normalized by, in this case, creating two alternatives, both containing an A assertion and a B assertion. One alternative contains a B assertion with a nested C assertion while the other contains a B assertion with a nested D assertion; Normalized form 4.1.5 Nested Policy Intersection Worked Example This section shows a worked example of computing the intersection of two policies that contain assertions with nested policy. Policy 1 Policy 2 The two policies above, which are already in normal form, are intersected as follows; firstly the QNames of the A and B assertions are intersected then the QNames of the nested assertions inside the B assertions are intersected. In the nested case, only the two B assertions that have nested C assertions match. Thus the intersection of the nested policy is; Intersected policy 4.2 Policy Subjects WS-PolicyAttachment defines various attachment points for policy. This section defines properties that are referenced later in this document describing the recommended or required attachment points for various assertions. In addition, Appendix A groups the various assertions according to policy subject. [Message Policy Subject] This property identifies a Message Policy Subject [WS-PolicyAttachment]. WS-PolicyAttachment defines seven WSDL [WSDL 1.1] policy attachment points with Message Policy Subject: wsdl:message A policy expression containing one or more assertions with Message Policy Subject MUST NOT be attached to a wsdl:message. wsdl:portType/wsdl:operation/wsdl:input, ./wsdl:output, or ./wsdl:fault A policy expression containing one or more assertions with Message Policy Subject MUST NOT be attached to a descendant of wsdl:portType. wsdl:binding/wsdl:operation/wsdl:input, ./wsdl:output, or ./wsdl:fault A policy expression containing one or more of the assertions with Message Policy Subject MUST be attached to a descendant of wsdl:binding. [Operation Policy Subject] A token assertion with Operation Policy Subject indicates usage of the token on a per-operation basis: wsdl:portType/wsdl:operation A policy expression containing one or more token assertions MUST NOT be attached to a wsdl:portType/wsdl:operation. wsdl:binding/wsdl:operation A policy expression containing one or more token assertions MUST be attached to a wsdl:binding/wsdl:operation. [Endpoint Policy Subject] A token assertion instance with Endpoint Policy Subject indicates usage of the token for the entire set of messages described for the endpoint: wsdl:portType A policy expression containing one or more assertions with Endpoint Policy Subject MUST NOT be attached to a wsdl:portType. wsdl:binding A policy expression containing one or more of the assertions with Endpoint Policy Subject SHOULD be attached to a wsdl:binding. wsdl:port A policy expression containing one or more of the assertions with Endpoint Policy Subject MAY be attached to a wsdl:port 5. Protection Assertions The following assertions are used to identify what is being protected and the level of protection provided. These assertions SHOULD apply to [Message Policy Subject]. Note that when assertions defined in this section are present in a policy, the order of those assertions in that policy has no effect on the order of signature and encryption operations (see Section 7.3). 5.1 Integrity Assertions Two mechanisms are defined for specifying the set of message parts to integrity protect. One uses QNames to specify either message headers or the message body while the other uses XPath expressions to identify any part of the message. 5.1.1 SignedParts Assertion The SignedParts assertion is used to specify the parts of the message outside of security headers that require integrity protection. This assertion can be satisfied using WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS. The binding details the exact mechanism by which the protection is provided. There MAY be multiple SignedParts assertions present. Multiple SignedParts assertions present within a policy alternative are equivalent to a single SignedParts assertion containing the union of all specified message parts. Note that this assertion does not require that a given part appear in a message, just that if such a part appears, it requires integrity protection. Syntax ... The following describes the attributes and elements listed in the schema outlined above: /sp:SignedParts This assertion specifies the parts of the message that need integrity protection. If no child elements are specified, all message headers targeted at the UltimateReceiver role [SOAP12] or actor [SOAP11] and the body of the message MUST be integrity protected. /sp:SignedParts/sp:Body Presence of this optional empty element indicates that the entire body, that is the soap:Body element, it's attributes and content, of the message needs to be integrity protected. /sp:SignedParts/sp:Header Presence of this optional element indicates a specific SOAP header (or set of such headers) needs to be protected. There may be multiple sp:Header elements within a single sp:SignedParts element. If multiple SOAP headers with the same local name but different namespace names are to be integrity protected multiple sp:Header elements are needed, either as part of a single sp:SignedParts assertion or as part of separate sp:SignedParts assertions. /sp:SignedParts/sp:Header/@Name This optional attribute indicates the local name of the SOAP header to be integrity protected. If this attribute is not specified, all SOAP headers whose namespace matches the Namespace attribute are to be protected. /sp:SignedParts/sp:Header/@Namespace This required attribute indicates the namespace of the SOAP header(s) to be integrity protected. 5.1.2 SignedElements Assertion The SignedElements assertion is used to specify arbitrary elements in the message that require integrity protection. This assertion can be satisfied using WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS. The binding details the exact mechanism by which the protection is provided. There MAY be multiple SignedElements assertions present. Multiple SignedElements assertions present within a policy alternative are equivalent to a single SignedElements assertion containing the union of all specified XPath expressions. Syntax ... The following describes the attributes and elements listed in the schema outlined above: /sp:SignedElements This assertion specifies the parts of the message that need integrity protection. If no child elements are specified, all message headers targeted at the UltimateReceiver role and the body of the message MUST be integrity protected. /sp:SignedElements/@XPathVersion This optional attribute contains a URI which indicates the version of XPath to use. /sp:SignedElements/sp:XPath This element contains a string specifying an XPath expression that identifies the nodes to be integrity protected. The XPath expression is evaluated against the S:Envelope element node of the message. Multiple instances of this element may appear within this assertion and should be treated as separate references in the signature. 5.2 Confidentiality Assertions Two mechanisms are defined for specifying the set of message parts to confidentiality protect. One uses QNames to specify either message headers or the message body while the other uses XPath expressions to identify any part of the message. 5.2.1 EncryptedParts Assertion The EncryptedParts assertion is used to specify the parts of the message that require confidentiality. This assertion can be satisfied with WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS. The binding details the exact mechanism by which the protection is provided. There MAY be multiple EncryptedParts assertions present. Multiple EncryptedParts assertions present within a policy alternative are equivalent to a single EncryptedParts assertion containing the union of all specified message parts. Note that this assertion does not require that a given part appear in a message, just that if such a part appears, it requires confidentiality protection. Syntax ... The following describes the attributes and elements listed in the schema outlined above: /sp:EncryptedParts This assertion specifies the parts of the message that need confidentiality protection. The single child element of this assertion specifies the set of message parts using an extensible dialect. If no child elements are specified, the body of the message MUST be confidentiality protected. /sp:EncryptedParts/sp:Body Presence of this optional empty element indicates that the entire body of the message needs to be confidentiality protected. In the case where mechanisms from WSS: SOAP Message Security are used to satisfy this assertion, then the soap:Body element is encrypted using the #content encryption type. /sp:EncryptedParts/sp:Header Presence of this optional element indicates that a specific SOAP header (or set of such headers) needs to be protected. There may be multiple sp:Header elements within a single Parts element. Each header or set of headers MUST be encrypted. Such encryption will encrypt such elements using WSS 1.1 Encrypted Headers. As such, if WSS 1.1 Encrypted Headers are not supported by a service, then headers cannot be encrypted using message level security. If multiple SOAP headers with the same local name but different namespace names are to be encrypted then multiple sp:Header elements are needed, either as part of a single sp:EncryptedParts assertion or as part of separate sp:EncryptedParts assertions. /sp:EncryptedParts/sp:Header/@Name This optional attribute indicates the local name of the SOAP header to be confidentiality protected. If this attribute is not specified, all SOAP headers whose namespace matches the Namespace attribute are to be protected. /sp:EncryptedParts/sp:Header/@Namespace This required attribute indicates the namespace of the SOAP header(s) to be confidentiality protected. so与such都有“如此、这么、那么”的意思，可进行同义改写，但用法不同。 1. so是副词，修饰形容词和副词；而such是形容词，修饰名词。它们后面接单数可数名词时，词序不同。 so的词序为：so+ adj. + a（an） + n. such的词序为：such +a（an） +adj. + n. 它们可以表达同样的意思，因此它们可以进行同义改写。 so nice a coat =such a nice coat 这么漂亮的一件外套 so interesting a book = such an interesting book 那么有趣的一本书 补给站：后面接复数名词或不可数名词时，只能用such，而不能用so.如： such beautiful flowers 这么美丽的花 such clever children 如此聪明的孩子 但是，复数名词或不可数名词前有many，few，much，little修饰时，只能用so而不能用such，这是一种固定用法。如： so many books 这么多书 so few people 这么少的人 so much money 那么多的钱 so little milk 那么少的牛奶 2. 和“that”连用时，意思基本一样，但句型结构不同。“so…that…”句型结构为： so + adj. （adv.） +that… so + adj. +a（an）+单数n. +that… so +many（few）+复数n. +that… so +much（little）+不可数n. +that…如： This book is so interesting that I have read it three times. 这本书如此有趣，我已经看了三遍。 He spoke so fast that we couldn‘t understand him. 他说得太快，我们都未能听懂他的话。 It was so hot a day that nobody wanted to do anything. 天气很热，谁都不想干活。 There were so many people that we could hardly move on. 这么多人，我们简直无法继续往前走。 “such…that…”句型结构为： such + a （an）+adj. +单数n. +that… such + adj. +复数n. +that… such +adj. +不可数n. +that… She is such a pretty girl that everyone likes her. 她是个很可爱的小姑娘，大家都喜欢她。 They are such delicious cakes that I want to eat another two. 这么可口的蛋糕，我还想再吃两块。 It is such sweet milk that we all want to drink it. 这么香的牛奶，我们都想喝。 补给站：由于so 和such后跟单数可数名词时，可以换用，同样“so…that…”与“such…that…”也可以进行同义句改写。如上文中：This book is so interesting that I have read it three times. 可改写成：This is such an interesting book that I have read it three times. It was so hot a day that nobody wanted to do anything. 可改写成：It was such a hot day that nobody wanted to do anything. 3. so与that可以直接构成词组“so that”，引导目的和结果状语从句，表示“以便、以致”的意思。如： He worked hard so that he could pass the exams. 为了能通过考试，他学习很认真。（但such没有这种用法） s o 和s u c h 用法小结 so和such用法小结 一,so的常见用法 1. 当so作副词，修饰形容词或副词时，表示程度，意为"这么","那么".如： Don' t be so silly. 别那么傻? He ran so fast. 他跑得那么快. 2. 如果so后无形容词，则so不能与名词连用.如: r ve n ever see n so tall a child(二such a tall child). 我从未见过个儿那么高的小孩? 切不可以说"He is so a child." 但是,so little,so much可与不可数名词连用,so few,so many可与复数名词连用 如： Tom ate so much food a meal. 汤姆一餐吃了那么多的食物. There' re so few people in the hall. 大厅里的人很少. 3.So…that意为"如此……以至于……",是一个常见句型,也是中考常考的句型 如:J ane' s leg was so painful that she couldn' t move at all. 简的腿那么疼，以至于根本动不了. 该句型还可以转换成"So + adj.+ a/an+名词"结构.如: Mike is so clever a boy that all like him. 麦克这么聪明,大家都喜欢他. so that意为"以便","为的是",引导目的状语从句(该目的状语通常用情态动词作 谓语)如: They can help you to compare two differe nt products so that you can buy the Such 和so 的用法: 如此…以致于… so+adj./adv.+that…. such+(a/an+adj.+)+n.+that… 特殊情况： 1.它们后面接单数可数名词时，词序不同。 so的词序为：so+ adj. + a（an）+ n. such的词序为：such +a（an）+adj. + n. so nice a coat =such a nice coat so interesting a book = such an interesting book 2.后面接复数名词或不可数名词时，只能用such，而不能用so.如： such beautiful flowers such clever children 3.名词前有many，few，much，little修饰时，只能用so 而不能用such，这是一种固定用法。 so many books so few people so much money so little milk 4. 和“that”连用时，意思基本一样，但句型结构不同。“so…that…”句型结构为： so + adj. （adv.）+that… so + adj. +a（an）+单数n. +that… so +many（few）+复数n. +that… so +much（little）+不可数n. +that… 这本书如此有趣，我已经看了三遍。 This book is so interesting that I have read it three times. It is such an interesting book that I have read it three times. It is so interesting a book that I have read it three times. 他说得太快，我们都未能听懂他的话。 He speak so quickly that we can’t understand him. 天气很热，谁都不想干活。 The weather is so hot that we don’t want to do anything. 这么多人，我们简直无法继续往前走。 There are so many people that we can’t go ahead. 5.“such…that…”句型结构为： such + a （an）+adj. +单数n. +that… such + adj. +复数n. +that… such +adj. +不可数n. +that… 她是个很可爱的小姑娘，大家都喜欢她。 She is such a lovely girl that we all like her. 这么可口的蛋糕，我还想再吃两块。 so 和such的用法区别 such, that 作“如此, 以致”解，连接一个表示结果的状语从句；与so, that 意思相同，但用法不同。如：so, that 这一结构中， so后边可加形容词或副词 1)so+adj.+an/a+单数可数名词+that You are so nice a boy that I want to make friends with you. It is so sunny a day that I want to have a walk outside. 2)so+adj.+that It's so cold that I don't want to go out. 而such后边要用名词（这个名词前面可以带形容词，也可以不带）。 such, that 的句型结构可分以下三种： 1) such＋a(an)＋adj.＋单数可数名词＋that He is such a clever boy that everybody likes him. 他非常聪明，大家都非常喜欢他。 He was such an honest man that he was praised by the teacher. 他非常诚实，因而受到了老师的表扬。 2)such＋adj.＋复数可数名词＋that They are such interesting novels that I want to read them once again. 这些小说非常有趣，我想再读一遍。 3)such＋adj.＋不可数名词＋that He has made such great progress that the teachers are pleased with him. 他进步得很快，老师们对他感到很满意。 注意：如果such 后边的名词前由many、much、few 、little 等词所修饰的话，则不用such 而用so。例如： He had so many falls that he was black and blue all over. 他摔了很多跤，以致于全身上下青一块，紫一块的。 He had so little education that he was unfit for this job. 他所受教育很少，不适合做这个工作。 There were so many people in the street watching the fire that firefighters could not get close to the building. 街上有那么多人观看大火，以致于消防队员无法接近大楼. 常用英文缩写-你不在外行 2 = to/too 2B or not 2B = To be or not to be 4 = for 4ever = forever A： ASL = Age/Sex/Location AFAIC = As Far As I’m Concerned AFAIK = As Far As I Know AFK = Away From Keyboard AIAMU = And I’m A Monkey’s Uncle AISI = As I See It AKA = Also Known As AMBW = All My Best Wishes ANFAWFOWS = And Now For A Word Word From Our Web Sponsor AOTS = All Of The Sudden ASAFP = As Soon As "Friggin" Possible ASAP = As Soon As Possible ATST = At The Same Time AWGTHTGTTA = Are We Going To Have To Go Through This Again AWGTHTGTTSA = Are We Going To Have To Go Through This Sh Again AYSOS = Are You Stupid Or Something B： B4 = Before B4N = Bye For Now BBFBBM = Body By Fisher, Brains by Mattel BBIAB = Be Back In A Bit BBIAF = Be Back In A Few BBL = Be Back Later BBN = Bye Bye Now BCNU = Be Seein’ You BF = Boyfriend BFD = Big Fing Deal BFN = Bye For Now BHOF = Bald Headed Old Fart BIF = Basis In Fact BITD = Back In The Day Biz = Business BM = Byte Me BMOTA = Byte Me On The Ass BNF = Big Name Fan BOHICA = Bend Over Here It Comes Again . . 小学英语中的缩写形式及完整形式 1．一般谢列词的时候，注意使用缩写形式。如： 含有am is are的时候。如： I’m=I am she’s=she is he’s=he is it’s = it is we’re = we are you’re =you are they’re=they are there’re=there are that’s=that is Sam’s a student.(Sam’s=Sam is是) 2．含有have，has以及他们的过去式had的时候，常用缩写式。 如： We’ve got a book.(we’re got=we have got) You’ve got=you have got they’ve got=they have got She’s got a cat.(she’s got=she has got) (he’s got=he has got it’s got=it has got) 3.含有not 的时候，常用缩写形式。如： isn’t=is not aren’t=are not can’t=can not that’s=that not let’s=let is my name’s=my name is 4. 含有would/should/had的时候，常用缩写形式。如： I’d=I would/should/had You’d=You would/should/had We’d=We would/should/had 5.过去时态否定形式的缩写 wasn’t=was not weren’t=were not so和such用法及区别全解 such和so两个单词意思相近，使用时很容易混淆。其实，这两个单词的用法并不相同，首先要注意的是，它们的词性不同；such 为形容词，意为“这（那）样的；这（那）种；如此的”，主要修饰名词；如： No such thing has ever happened. I have never seen such a beautiful place before. 而so是副词，意为“这（那）么；这（那）样；如此地”，主要修饰形容词、副词和分词。如： Last time I saw him he was so fat! He was not so much angry as disappointed. 但是，such和so都可以用于名词词组。本文主要介绍一下它们在名词词组中的用法。 一、后接可数名词的单数形式 1、直接跟名词时，用such；如： However did you make such a mistake? I have never heard of such a thing. Why are you in such a hurry? ēQ|ほīｗwW．CＩHＵｉ．Ｂｉｚ∏θ∫ミ 注意：当such前面有no时，必须省去不定冠词a(an)，因为no such 本身已经包括了不定冠词，相当于not such a(an)；如： I have no such book. (= I haven’t such a book.) 2、跟带有形容词的名词时，既可以用such，也可以用so，但应注 意冠词位置的不同，如： I have never seen such a tall man. I have never seen so tall a man. He is not such a clever boy as his brother. He is not so clever a boy as his brother. 二、后接可数名词的复数形式或集合名词，无论有无修饰语都用such，如：Such things often happen in our daily life. Such people are dangerous. Whales are such smart animals that they communicate with each other. He made such stupid mistakes that the teacher tore up the whole paper. 三、后接不可数名词，无论有无修饰语都用such，如： Did you ever see such weather? You can’t drink such hot milk. She made such rapid progress that she soon began to write articles in English. 四、当复数名词或集合名词之前有few，many；不可数名词之前有little，much修饰时，用so，如： so many people / so many students / so few days so much time / so much money / so little time等。 注意：上述词组中的so实际上修饰名词前的形容词。比较下列两 索罗学院 常见的缩写形式有哪些? 常见的缩写形式： I'm=I am 我是 she's=she is 她是he's=he is 他是it's=it is 它是we're=we are 我们是you're=you are 你是;你们是they're=they are 它们是;他们是;她们是 there's=there is 有…there're=there are 有…that's=that is 那是…isn't=is not不是aren't=are not不是wasn't=was not不是(过去式) weren't=were not 不是(过去式) don't=do not 不，没有doesn't=does not不，没有(单三形式) didn't=didn't 不，没有(过去式) hasn't=has not 还没有(单三形式的现在完成时) haven't= have not 还没有(现在完成时) hadn't=had not 还没有(过去完成时) can't=can not 不能won't=will not 不会Let's=Let us 让我们(提建议) could-couldn't 不能(过去式) 星期的缩写，要记住加一点：星期一：Monday=Mon. 星期二：Tuesday=Tue. 星期三：Wednesday=Wed. 星期四：Thursday=Thur. (缩写后是4个字母) 星期五：Friday=Fri. 星期六：Saturday=Sat. 星期天：Sunday=Sun. 月份的缩写，后面的点不能忘带：Jan. 一月Feb. 二月Mar. 三月Apr. 四月May 五月(没有缩写形式) Jul. 六月Jun. 七月Aug. 八月Sept. 九月 (缩写后是4个字母) Oct. 十月Nov. 十一月Dec. 十二月 注：上面列出了初中阶段常用的所有的缩写形式，大家按照自己的所处阶段选择性的记忆。 本文由索罗学院整理 索罗学院是一个免费的中小学生学习网，上面有大量免费学习视频，欢迎大家前往观看！ so与such用法，练习 So与Such都有“如此、这么、那么”的意思，可进行同义改写，但用法不同。 1. so是副词，修饰形容词和副词；而such是形容词，修饰名词。它们后面接单数可数名词时，词序不同。 so的词序为：so+ adj. + a（an）+ n. such的词序为：such +a（an）+adj. + n. 它们可以表达同样的意思，因此它们可以进行同义改写。 so nice a coat =such a nice coat 这么漂亮的一件外套 so interesting a book = such an interesting book 那么有趣的一本书 注意：后面接复数名词或不可数名词时，只能用such，而不能用so.如： such beautiful flowers 这么美丽的花such clever children 如此聪明的孩子 但是，复数名词或不可数名词前有many，few，much，little(少) 修饰时，只能用so而不能用such，这是一种固定用法。如： so many books so few people so much money so little milk 2. “so…that…”句型结构为：如此…以至于” so + adj. （adv.）+that… so + adj. +a（an）+单数n. +that… so +many（few）+复数n. +that… so +much（little）+不可数n. +that…如： This book is so interesting that I have read it three times. He spoke so fast that we couldn’t understand him. It was so hot a day that nobody wanted to do anything. There were so many people that we could hardly move on. “such…that…”如此…以至于 such + a （an）+adj. +单数n. +that… such + adj. +复数n. +that… such +adj. +不可数n. +that… She is such a pretty girl that everyone likes her. They are such delicious cakes that I want to eat another two. It is such sweet milk that we all want to drink it. 注：由于so 和such后跟单数可数名词时，可以换用，同样“so…that…”与“such…that…”也可以进行同义句改写。如上文中： This book is so interesting that I have read it three times. -- This is such an interesting book that I have read it three times. 3. so与that可以直接构成词组“so that”，引导目的和结果状语从句，表示“以便于、为了”的意思。如： He worked hard so that he could pass the exams.（但such没有这种用法） 不知道啥意思，看看后面有东西，估计就是让看吧，并且有点尊敬的意思！最后才知道事For your information~ 有次和外国客户发邮件。有个LMK的缩写。想了半天，后天查了网络，才知道是LET ME KNOW 的意思。我没有想的那么正确。所以知道一些简单的缩写是很有必要的，我在网上查了一些。不知道你们之前看过没。 数字： 2 = to/too 2B or not 2B = To be or not to be 4 = for 4ever = forever A： ASL = Age/Sex/Location AFAIC = As Far As I’m Concerned AFAIK = As Far As I Know AFK = Away From Keyboard AIAMU = And I’m A Monkey’s Uncle AISI = As I See It AKA = Also Known As AMBW = All My Best Wishes ANFAWFOWS = And Now For A Word Word From Our Web Sponsor AOTS = All Of The Sudden ASAFP = As Soon As "Friggin" Possible ASAP = As Soon As Possible ATST = At The Same Time AWGTHTGTTA = Are We Going To Have To Go Through This Again AWGTHTGTTSA = Are We Going To Have To Go Through This Sh Again AYSOS = Are You Stupid Or Something B： B4 = Before B4N = Bye For Now BBFBBM = Body By Fisher, Brains by Mattel BBIAB = Be Back In A Bit BBIAF = Be Back In A Few BBL = Be Back Later BBN = Bye Bye Now BCNU = Be Seein’ You BF = Boyfriend BFD = Big Fing Deal BFN = Bye For Now such a + n. 都表示“如此的。。。。” so与such的词性不同。 such 是形容词，修饰名词或名词词组， so是副词，只能修饰形容词或副词。 so 还可与表示数量的形容词many，few，much，little连用，形成固定搭配。 so + adj. such + a(n) + n. so + adj. + a(n) + n. such + n. (pl.) so + adj. + n. (pl.) such +n. (pl.) so + adj. + n. [不可数] such +n. [不可数] so foolish such a fool so nice a flower such a nice flower so many/ few flowers such nice flowers so much/little money. such rapid progress so many people such a lot of people so many 已成固定搭配，a lot of 虽相当于many，但a lot of 为名词性的，只能用such搭配。 so…that与such…that之间的转换既为so与such之间的转换。 (1)such 后面加名词so 后面加形容词 但出现many,much,few,little时用so (2)so+adj/adv+that 从句 (3)so+adj+a/an+单数可数名词 (4) such +a/an(adj)+ 单数可数名词( 这也是一个不同点,注意形容词与+a/an 的位子) so副词，意思是“如此、这样”，后面常接形容词或副词；such形容词，意思是“如此、这样”，修饰名词，即可接可数名词，也可以接不可数名词。例如： It’s such a fine day. It’s so fine a day. 从上面两例可以看出： such修饰单数可数名词时，不定冠词a/an通常放在such之后紧挨着；而so则不同，不定冠词位置不同。其结构分别为： such与so的区别与用法 such与so的意思都是“如此，这样”。但两者用法根本不同，与what和how引导的感叹句相类似。 1、such后面主要是修饰名词。即：such＋a/an＋adj.＋n.或a/an＋such＋adj.＋n.。如果名词是不可数名词或复数名词，则不可以用不定冠词a或an。如： ①He has such a beautiful bike. We all go to see it. ②It's a such fine day. We all want to go to fly a kite. 2、so后面只能跟形容词或副词。即：so＋adj./adv.不过，so后面也可以跟名词，但该名词必须是单数可数名词。用法为：so+形容词+a/an+单数可数名词。如： ①The tiger is so big. And the cat is so small. ②She is so lovely a girl. 3、它们后面还可以与that从句连用。即：such…that和so…that意思是“如此……以至……”。如： ①She is such a clever girl that she can make much progress in math exam. ②His brother is so young that he can't go to school. 注：当名词前的形容词为表示数目的词时，such必须换成so。如： ①There are so many people that we can't go past. ②I ate so much food that I didn't want to go any farther. Smith has made so much progress that we are all surprised. 进步是不可数名词，因此用much（修饰不可数名词. many修饰可数名词。 so是副词,只能修饰形容词或副词。只有so能与much连用。一般来说，so many 和so much可以成为固定的词组 so...that...”句型的意思是“如此/这么……以致于……”，常引导结果状语从句，但“so...that...”是个爱“变脸”句型，你一不留意就会出错。“so...that...”句型及其转换也是中考的热点，现将其用法总结归纳如下，让我们一起来看看它是怎样变的吧。 一、so... that...句型中的so是副词，常常用来修饰形容词或副词，常用句型为：主语+谓语+so+adj. / adv. + that从句。例如： 1. he is so young that she can't look after herself. 2. The boy ran so fast that I couldn't catch him. 3. He was so angry that he couldn't say a word. 二、在“such... that...”句型中，such修饰名词，意思也是“如此……以致于……”但当名词前有many、much、(a) few、(a) little等词修饰时，句子中要用“so...that...”而不能用“such...that...”。例如： 1. He has so much money that he can buy what he wanted. so…that和such…that的用法区别 s uch…that作“如此…以致”解，连接一个表示结果的状语从句；与so…that 意思相同，但用法不同。如：so…that这一结构中，so后边可加形容词或副词，而such后边要用名词（这个名词前面可以带形容词，也可以不带）。 因此，such…that的句型结构可分以下三种： 1) such＋a(an)＋adj.＋单数可数名词＋that…clause He is such a clever boy that everybody likes him. 他非常聪明，大家都非常喜欢他。 He was such an honest man that he was praised by the teacher. 他非常诚实，因而受到了老师的表扬。 2)such＋adj.＋复数可数名词＋that…clause They are such interesting novels that I want to read them once again. 这些小说非常有趣，我想再读一遍。 3)such＋adj.＋不可数名词＋that…clause He has made such great progress that the teachers are pleased with him. 他进步得很快，老师们对他感到很满意。 注意：如果such后边的名词前由many、much、few、little等词所修饰的话，则不用such 而用so。例如： He had so many falls that he was black and blue all over. 他摔了很多跤，以致于全身上下青一块，紫一块的。 He had so little education that he was unfit for this job. 他所受教育很少，不适合做这个工作。 There were so many people in the street watching the fire that firefighters could not get close to the building. 街上有那么多人观看大火，以致于消防队员无法接近大楼. 它们的区别主要有三个： 1）so+形容词+a(n)+名词+that such+a(n)+形容词+名词+that 2)当形容词后跟名词复数或不可数名词时，只能用such 3）当名词前有many,few,much,little修饰，只能用so 1. CC 抄送 Literal meaning: Carbon Copy. When used in an e-mail, it means to send a copy of the e-mail to someone else. Hidden meaning: If you are on the CC list, you may simply read the e-mail. You're not always obligated to reply. But if an e-mail sent to you has your boss' e-mail on the CC l ist, watch out. When the boss is involved, you'd better take the e-mail more seriously. 2. FYI 供你参考 Literal meaning: For your information. Hidden meaning: By adding "FYI", the sender indicates that the e-mail contains informatio n that may be valuable to your company or job responsibilities. 3. ASAP / urgent 紧急文件 Literal meaning: As soon as possible. Hidden meaning: When you see "ASAP" or "urgent" in an e-mail or document, you shoul d quickly carry out th e e-mail's orders. 4. RESEND! 重传 Literal meaning: Please resend your reply to me. Hidden meaning: "I haven't received your reply. I don't have much time. Please hurry." Y ou might get such a message from someone who sent you an e-mail, to which you've yet to reply. others: 数字： 2 = to/too 2B or not 2B = To be or not to be 4 = for 4ever = forever A： ASL = Age/Sex/Location AFAIC = As Far As I’m Concerned AFAIK = As Far As I Know AFK = Away From Keyboard AIAMU = And I’m A Monkey’s Uncle AISI = As I See It already, yet , still He’s already finished his work. （已经） He has not finished his work yet. （尚未） Are you still learning French? （仍然） Have you met Mr. Wang yet? （你见过王先生没有？一般疑问） Have you already met Mr. Wang? （你已经见过王先生了？/ 表示意外） too, also, either 注意位置和区别的对象： I like to play football, too. （可能区别的是主语或其它部分） I , too, like football. （可能区别的是主语或其它部分） I also like to play football. （区别的不能是主语） I don’t like to play football, either. （否定句） so与such都有“如此、这么、那么”的意思，可进行同义改写， 但用法不同。 1. so是副词，修饰形容词和副词；而such是形容词，修饰名词。它们后面接单数 可数名词时，词序不同。 so的词序为：so+ adj. + a（an） + n. such的词序为：such +a（an） +adj. + n. 它们可以表达同样的意思，因此它们可以进行同义改写。 so nice a coat =such a nice coat 这么漂亮的一件外套 so interesting a book = such an interesting book 那么有趣的一本书 补给站：后面接复数名词或不可数名词时，只能用such，而不能用so.如： such beautiful flowers 这么美丽的花 such clever children 如此聪明的孩子 但是，复数名词或不可数名词前有many，few，much，little修饰时，只能用so而不能用such，这是一种固定用法。如： so many books 这么多书 so few people 这么少的人 so much money 那么多的钱 so little milk 那么少的牛奶 2. 和“that”连用时，意思基本一样，但句型结构不同。“so…that…”句型结构为： so + adj. （adv.） +that… so + adj. +a（an）+单数n. +that… so +many（few）+复数n. +that… 英语缩写形式及完全 形式 主格八人称: I you he she it we you they 我是I 你是YOU, he she it他(她/它)全 有, we是我们you你们, they是他们(她们/它 们)要记真. 1.主格八人称和is am are 的缩写 缩写形式完全形式 1) I’m = 2) you’re = 3) she’s = 4) he’s = 5) we’re = 6) they’re = 7) it’s = 2.主格八人称和will的 缩写 缩写形式完全形式 1) I’ll = 2) you’ll = 3) she’ll = 4) he’ll = 5) we’ll = 6) they’ll = 7) it’ll = 8) won’t = 3. is are 和not的缩写 缩写形式完全形式缩写形式完全形式 isn’t = aren’t = 4. 主格八人称和have has的缩写 缩写形式完全形式 1) I’ve got = (我有) 2) you’ve got = (你有) 3) we’ve got = (我们有) 4) they’ve got = (他们有) 5) she’s got = (她有) 6) he’s got = (他有) 7) it’s got = (它有) 8) haven’t = 9) hasn’t = 5. 其它的缩写 what’s = who’s = where’s= where’re = don’t = doesn’t= can’t = that’s = let’s = my name’s = 5. 过去时态的一些缩 写 wasn’t = weren’t = such和so都可以用来表示程度，意思是“如此；这样”，但用法却不相同。1．such是形容词，用来修饰名词，名词前有无形容词都可以；so是副词，用来修饰形容词或副词，形容词后可以省略名词。例如： He is such a（big）fool．他是个（大）傻瓜。 He is so foolish（a man）．他是如此愚蠢（的一个人）。 2．单数名词前有不定冠词与形容词时，so和such的位置不同。前者为“so＋形容词＋冠词＋名词”，后者为“such ＋冠词＋形容词＋名词”。例如： I know such a clever boy．我认识如此聪明的一个男孩。 I know so clever a boy．我认识如此聪明的一个男孩。 3．so后即使有形容词，也不能修饰复数名词或不可数名词，而such则可以。例如： They are such useful books．它们是如此有用的书。 He gave us such good food．他给了我们这么好的食物。 4．名词前有表示“多、少”意义的many，much，few，little等修饰词时，要用so，不用such。例如： There are so many flowers in our school garden．我们学校的花园里有那么多的花。You'll find English a bridge to so much knowledge．你会发现英语是通向如此丰富知识的桥梁。 I have so little money that I can't lend you any．我的钱很少，不能借给你。 5．当little表示“小”的意思修饰可数名词时，其前只能用such，不能用so。例如：I have never seen such little sheep before．我以前从没见过这么小的绵羊。such…that作“如此…以致”解，连接一个表示结果的状语从句。与so…that 意思相同，但用法不同。如：so…that这一结构中，so后边可加形容词或副词，而such后边要用名词（这个名词前面可以带形容词，也可以不带）。因此，such…that的句型结构可分以下三种： 1) such＋a(an)＋adj.＋单数可数名词＋that…clause he is such a clever boy that everybody likes him. 他非常聪明，大家都非常喜欢他。 he was such an honest man that he was praised by the teacher. 他非常诚实，因而受到了老师的表扬。 2)such＋adj.＋复数可数名词＋that…clause they are such interesting novels that i want to read them once again. 这些小说非常有趣，我想再读一遍。 3)such＋adj.＋不可数名词＋that…clause he has made such great progress that the teachers are pleased with him. 他进步得很快，老师们对他感到很满意。 注意：如果such后边的名词前由many、much、few、little等词所修饰的话，则不用 such而用so。例如： he had so many falls that he was black and blue all over. 他摔了很多跤，以致于全身上下青一块，紫一块的。 he had so little education that he was unfit for this job.so与such用法
so和such用法小结教学教材
so-such-用法及练习题
such和so的用法区别 包含答案
常用英文缩写-你不在外行
小学英语中的缩写形式及完整形式
so和such用法及区别全解41450
常见的缩写形式有哪些
so与such用法
必须知道的英文缩写
such,such a 和so三者的区别
so 和such 用法
(完整版)so…that和such…that的用法区别
英文缩写参考版本
so与such用法
英语缩写形式及完全形式
such,so的用法
相关主题
文本预览