WCF provides inbuilt service security, need to configure only as per requirements.
Message Security: This is end to end security, encrypted & signed messages transported, security is in messages itself. Its recommended when some other mediator (service, external routers) exist between client and service. Our won (custom) algorithms can be used for encryption/decryption.
User and Password need to pass to service before calling service methods.
Modes of security to achieve transfer security
This security achieved by by transport protocol https using SSL certificate. SSL (Secure Sockets Layer) certificate is supplied by Microsoft, its paid.
Transport security is available for all bindings except 'wsDualHttpBinding'.
Transport security is based on
Protection levels in message security:
Scenarios to use:
Message Security: This is end to end security, encrypted & signed messages transported, security is in messages itself. Its recommended when some other mediator (service, external routers) exist between client and service. Our won (custom) algorithms can be used for encryption/decryption.
User and Password need to pass to service before calling service methods.
Modes of security to achieve transfer security
- Transport
- Message
- TransportWithMessageCredential
This security achieved by by transport protocol https using SSL certificate. SSL (Secure Sockets Layer) certificate is supplied by Microsoft, its paid.
Transport security is available for all bindings except 'wsDualHttpBinding'.
Transport security is based on
- Caller authentication
- Message integrity
- Message Confidentiality
- Intranet (Client and service are in same network)
- Client & server communicating directly, there is no other intermediate system
(If there is some intermediate system that also should communicate on new SSL).
- Caller need not to understand WS security specifications
- Better performance
- Hardware accelerators can be used for more better performance
- Recommended scenarios are intranet, or point to point means there transport should not done through some other intermediate system
- Provide limited set of credentials
Message Security
In message security credentials are encapsulated with every message & messages are encrypted & signed. It uses WS-Security specifications for message security, WS-Security specifications specify enhancements on SOAP.
If we are using ClientCredentialType 'windows' then service uses windows credentials in token to secure messages. Other than windows authentication types are 'Certificate', 'UserName', 'IssuedToken' these all are required service certificate that is used to secure messages.
Service uses service certificate as authentication token.
Protection levels in message security:
- None
- Sign
- EncryptAndSign
Service level
[ServiceContract(ProtectionLevel
= ProtectionLevel.EncryptAndSign)]
public interface IService1
{}
{}
Operation level
[OperationContract(ProtectionLevel = ProtectionLevel.Sign)]
[OperationContract(ProtectionLevel = ProtectionLevel.Sign)]
CompositeType GetDataUsingDataContract(CompositeType composite);
Message level
[MessageContract(ProtectionLevel = ProtectionLevel.None)]
[MessageContract(ProtectionLevel = ProtectionLevel.None)]
public class CompositeType
{}
Message Member’s level
[MessageBodyMember(ProtectionLevel= ProtectionLevel.Sign)]
bool boolValue = true;[MessageBodyMember(ProtectionLevel= ProtectionLevel.Sign)]
Scenarios to use:
- Client & service communicating on internet
- Intermediate system (other service(s)) exist in between client & service
Advantages:
- It provide end to end security, independent from transport, so transport security not required
- Messages are signed & encrypted so intermediate system(s) can't break security
- It provides wide set of credential options 'Windows', 'Certificate', 'UserName' & 'IssuedToken'
- It allows partials or selective singing & encryption 'Sign', 'EncryptAndSign' & 'None'
Disadvantages:
- Performance consideration because every message is signed & encrypted
- Doesn't support interoperability with old asmx clients because it required WS-Security specifications to be followed by client & service both for encryption and sign




No comments:
Post a Comment