MessageContractMemberAttribute.ProtectionLevel Property
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Specifies whether the member is to be transmitted as-is, signed, or signed and encrypted.
public:
property System::Net::Security::ProtectionLevel ProtectionLevel { System::Net::Security::ProtectionLevel get(); void set(System::Net::Security::ProtectionLevel value); };public System.Net.Security.ProtectionLevel ProtectionLevel { get; set; }member this.ProtectionLevel : System.Net.Security.ProtectionLevel with get, setPublic Property ProtectionLevel As ProtectionLevelProperty Value
One of the ProtectionLevel values. The default is None.
Remarks
To make use of the ProtectionLevel property in either the MessageHeaderAttribute or MessageBodyMemberAttribute attributes you must properly configure the binding and behaviors. If these security features are used without a proper configuration (for example, using ProtectionLevel.Sign with a message part without supplying security credentials) an exception is thrown at run time.
In addition, the protection level is determined for each header individually. However, the SOAP body has only one protection level, regardless of the number of body parts. The protection level of the body is determined by the highest ProtectionLevel property value of all the body parts. For example, consider the following class:
[MessageContract]
public class PatientRecord
{
[MessageHeader(ProtectionLevel=None)] public int recordID;
[MessageHeader(ProtectionLevel=Sign)] public string patientName;
[MessageHeader(ProtectionLevel=EncryptAndSign)] public string SSN;
[MessageBody(ProtectionLevel=None)] public string comments;
[MessageBody(ProtectionLevel=Sign)] public string diagnosis;
[MessageBody(ProtectionLevel=EncryptAndSign)] public string medicalHistory;
}
In this example, the recordID header is not protected, patientName is signed, and SSN is encrypted and signed. There is at least one body part, medicalHistory, with ProtectionLevel.EncryptAndSign and thus the entire message body is encrypted and signed, even though the comments and diagnosis body parts specify lower protection levels.
The protection behavior at runtime is the combination of the protection-level values set on the following properties. These properties have a hierarchical structure. Setting the outermost value establishes the default setting for all narrower scopes unless a different value for a narrower scope is explicitly set. In this case, the outer value remains the default for all narrower scopes with the exception of that specifically set.
For example, if ServiceContractAttribute.ProtectionLevel is set to ProtectionLevel.EncryptAndSign and no other narrower scopes have protection level settings, all messages in an operation contract are encrypted and signed. If, however, one of those operations has the OperationContractAttribute set to ProtectionLevel.Sign, then the messages for that operation are signed but all other messages in the contract are encrypted and signed.
For details about protection levels and their assumptions and scopes, see Understanding Protection Level.
The scopes at which these values are set are:
ServiceContractAttribute.ProtectionLevel
OperationContractAttribute.ProtectionLevel
FaultContractAttribute.ProtectionLevel
MessageContractAttribute.ProtectionLevel
The MessageContractMemberAttribute.ProtectionLevel property on System.ServiceModel.MessageHeaderAttribute.
The MessageContractMemberAttribute.ProtectionLevel property on System.ServiceModel.MessageBodyMemberAttribute.
When there is no protection level explicitly specified on the contract and the underlying binding supports security (whether at the transport or message level), the effective protection level for the whole contract is ProtectionLevel.EncryptAndSign. If the binding does not support security (such as BasicHttpBinding), the effective System.Net.Security.ProtectionLevel is ProtectionLevel.None for the whole contract. The result is that depending upon the endpoint binding, clients can require different message or transport level security protection even when the contract specifies ProtectionLevel.None.
