¿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");
}
}
}
