Escenarios de seguridad en WCF: A nivel de Mensaje

¿Transporte o Menaje? Bien, según el escenario, aunque ahora no hablaré de ello (quizás otro post). Ante la posibilidad de implantación de servicios desarrollados con WCF, se presentan varios escenarios dónde la utilización de los mismo vienen, sino determinada, sí influenciada por su política de seguridad.

Modos de seguridad hay 5 [None, Transport, Message, Both, TransportWithMessageCredentials, TransportCredential Only], si quereis ampliar información mirar aqui.

Message Security with Username Client

Ante este contexto explicaré tres posible modos de autenticación UserName. Primeramente saber que en los tres modos de autenticación en el Servidor debe existir un certificado X509 para que el cliente pueda constatar la autenticidad del servicio. Si quereis más info de como crearlo mirar aqui.

En el intercambio inicial desde una llamada del cliente los datos en formato binario son trasportados mediante la especificación WS-Trust (véase TLS Negotiation). Una vez el servicio ha sido autenticado se establece un contexto de seguridad compartido [Shared security context].

Los mensajes, por defecto, están encriptados y firmados (véase ProtectionLevel ) y són transportados bajo dicho contexto de seguridad. La peculiaridad de este escenario és que el cliente es autenticado mediante un User y un Password. El tipo de enlace es wsHttpBinding, el transporte HTTP.

Modos de Autenticación:

* Utilizando autenticación por Windows: El tipo de credencial por UserName requiere de un valor User y otro Password que se deberán especificar a la hora de llamar desde el cliente mediante la propiedad clienteproxy.ClientCredentials.UserName.User o Password. Bajo el escenario en que nos encontramos, si no se especifica el tipo concreto de autenticación será, por defecto, autenticación Windows. Es decir que si en la llamada pasamos en User algo tal que 'Dominio\Usuario' con el respectivo password, la autenticación, con el permiso del controlador de dominio, se validará.

* Utilizando autenticación MemberShip: Pues como si se tratara de un site en ASP.NET podemos utilizar la misma funcionalidad. De entrada se me ocurre como ideal si se va a consumir por Internet y/o se va a utilizar la misma autenticación de nuestra site web o Intranet. Sin embargo, debemos indicar en el comportamiento del servicio (ServiceBehaviors\Behavior\ServiceCredentials) del archivo de configuración el tag siguiente:

[userNameAuthentication="MembershipProvider" membershipProviderName="SqlMembershipProvider"]

En este punto los valores que debemos pasar como User y Password són los que tenemos asignados dentro de Membership. Un buen documento que profundiza más es el siguiente.

* Otro escenario, quizás algo menos útil [aparentemente, opinión personal], pero mucho más flexible es mediante la autenticación parametrizada o customizada. Esto es, añadiendo una clase a nuestro Proyecto Servicio, que herede de UserNamePasswordValidator y sobreescribiendo (override) el método Validate, cuyos parámetros son user y password del tipo string, podremos manipularlos de la forma que queramos. Para ello el tag a añadir es:

[usernameauthentication="Custom" membershipProviderName="mypoject.myservice.CustomUserNameValidator, Project1"]

Dónde indicamos la clase que manejará la autenticación (CustomUserNameValidator), que hereda de UserNamePasswordValidator, y que está en el ensamblado (proyecto) Project1.

Ejemplo:

public class CustomUserNameValidator : UserNamePasswordValidator {
public override void Validate(string userName, string password) {
if (userName != "miusuario" password != "mipwd") {
throw new SecurityTokenException("Usuario/Contraseña incorrecta");
}
}
}