Securing Internet Services

When remote clients are not part of the Windows domain, they use Internet protocols to access services (HTTP or HTTPS). The configuration settings in this case will vary based on many factors, including the type of protocols client applications can support. You’ll usually want to expose services so that they can be accessed by earlier web service protocol stacks (Basic Profile) while also supporting emerging web service standards (WS*). I discussed this type of scenario in Chapter 3, without specifically discussing security-related standards. By the same token, you have to consider exposing endpoints with security policies that can be met by your intended client base.

Assuming you want to support interoperability and reach clients using earlier and more recent web service technologies, in addition to clients that support WS*, you’ll likely expose several secure service endpoints meeting the following requirements:

  • One endpoint can expose a SOAP 1.1 endpoint and comply with Basic Security Profile using SSL/HTTPS for server authentication and message protection or WS-Security.

  • Another endpoint can expose a SOAP 1.2 endpoint and use existing and emerging web service security standards such as WS-Security and WS-SecureConversation for server authentication and message protection.

  • Both endpoints require UserName credentials for client authentication.

  • Authentication and authorization use the built-in ASP.NET membership and role provider.

  • Services are hosted in IIS. ...

Get Learning WCF now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.