Editar:
Ya han pasado varios años desde que escribí por primera vez la respuesta y la lista se está haciendo vieja. Se ha producido una amplia adopción de API habilitadas para la web y retransmisión de confianza basada en token.
No lo he leído, pero Windows Communication Foundation Security sería un buen lugar para comenzar, si está buscando algo específico para WCF.
También mantenga sus ojos abiertos para lo que están haciendo los principales jugadores como Facebook, Google y Twitter. Están utilizando protocolos abiertos como OpenID y OAuth. Al principio, OAuth parece complicado, pero debes entender el mecanismo.
En mi opinión, OAuth reinventa muchas ruedas que SSL ya ha resuelto y deja algunos agujeros de seguridad abiertos. Una lectura interesante es Compromising Twitter's OAuth security system. Facebook's OAuth 2.0 implementation y Google's OAuth 2.0 implementation simplifican muchos de estos problemas al usar https donde tiene sentido. Estas son lecturas obligatorias.
El concepto básico en torno OAuth es la retransmisión de confianza. Desearía que los desarrolladores externos hicieran aplicaciones contra su API, pero los usuarios finales no siempre pueden confiar en estas aplicaciones. Darles una contraseña es como dar las llaves del reino. Entonces, el usuario ingresa la contraseña en su UI y su UI redirige a un tercero con un token de acceso.
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication es una buena introducción a los modelos de seguridad de ASP.NET. Puede omitir los detalles porque gran parte de la tecnología ahora está obsoleta.
Una buena descripción general de los servicios web es Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0. Dice WSE, pero los conceptos básicos siguen siendo los mismos.
Para obtener más información sobre WS-Security, lea Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption.
Securing Web Services with WS-Security http://ecx.images-amazon.com/images/I/51QPQ9QRZQL._SL500_AA240_.jpg
Después de leer por encima, lo que realmente me ayudó estaba buscando en las implementaciones existentes como Amazon S3's authentication:
Amazon S3's authentication http://docs.amazonwebservices.com/AmazonS3/2006-03-01/images/HMACAuthProcess_You.gif
Flickr Authentication API:
Cada FROB autenticación es específica a una usuario y la api de una aplicación clave, y solo se puede usar con esa clave .
frobs de autenticación son válidos durante 60 minutos desde el momento de su creación, o hasta que la aplicación llama flickr.auth.getToken, lo que sea antes.
Solo una autenticación frob por aplicación por usuario será válida en en cualquier momento. Las aplicaciones deben tratar con con vencimientos de autenticación caducados e inválidos y saber cómo renovarlos al .
Twitter REST API
Muchos métodos de la API de Twitter se requieren autenticación. Todas las respuestas son en relación con el contexto del usuario autenticador . Por ejemplo, un intento de para recuperar información en un usuario protegido que no es amigo de , fallará el usuario solicitante.
En el momento, HTTP Basic Autenticación es el único esquema de autenticación admitido . Cuando se autentica mediante a través de Basic Auth, use su nombre de usuario registrado o dirección de correo electrónico como componente de nombre de usuario. Las cookies de sesión y el inicio de sesión basado en parámetros se sabe que funcionan, pero no son oficialmente compatibles.
El esquema de autenticación token OAuth será que se ofrecerá en breve como versión experimental beta.
Así que es bueno saber los certs complicados y las cosas de PKI, pero el mundo parece funcionar sin él muy bien.
+1 para hacer un esfuerzo adicional en esta respuesta! – mhenrixon
+1 ¡justo lo que necesitaba! – Tim