web-services - services - wsse-password type c#
Ejemplo de solicitud SOAP autenticada con WS-UsernameToken (4)
Estoy intentando autenticar una solicitud SOAP utilizando la especificación WS-UsernameToken, pero el dispositivo de destino siempre está denegando el acceso. Mi solicitud de no trabajo se ve así. (La contraseña que estoy tratando de hash es el system .)
<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope">
<Header>
<Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<UsernameToken>
<Username>root</Username>
<Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">EVpXS/7yc/vDo+ZyIg+cc0fWdMA=</Password>
<Nonce>tKUH8ab3Rokm4t6IAlgcdg9yaEw=</Nonce>
<Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2010-08-10T10:52:42Z</Created>
</UsernameToken>
</Security>
</Header>
<Body>
<SomeRequest xmlns="http://example.ns.com/foo/bar" />
</Body>
</Envelope>
Lo que estoy buscando es un ejemplo de solicitud similar, pero con el token de autenticación que realmente funciona. Por ejemplo, si tiene la aplicación gSOAP que usa estos token y puede generar una solicitud y publicar el resultado aquí, le estaré muy agradecido.
Lo principal es definir los prefijos para los espacios de nombres y usarlos para fortalecer cada etiqueta: estás mezclando 3 espacios de nombres y eso simplemente no funciona al tratar de piratear los valores predeterminados. También es bueno usar exactamente los prefijos utilizados en el estándar do c, en caso de que el otro lado quede un poco descuidado.
Por último, pero no menos importante, es mucho mejor usar los tipos predeterminados para los campos siempre que pueda. Por lo tanto, para la contraseña debe indicar el tipo, para el Nonce ya es Base64.
Asegúrese de verificar que el token generado sea correcto antes de enviarlo a través de XML y no olvide que el contenido de wsse: Password es Base64 (SHA-1 (nonce + created + password)) y fecha y hora en wsu: Creado puede fácilmente arruinarte. Entonces, una vez que arregle los prefijos y los espacios de nombres y verifique que SHA-1 funciona bien sin XML (solo imagine que está validando la solicitud y realiza el cálculo de SHA-1 del lado del servidor), también puede hacer un truial wihtout Created e incluso sin Nonce. Oh y Nonce pueden tener diferentes codificaciones, así que si realmente quieres forzar otra codificación, tendrás que buscar más en el espacio de nombres wsu.
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu= "...">
<S11:Header>
...
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>NNK</wsse:Username>
<wsse:Password Type="...#PasswordDigest">weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse:Password>
<wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
<wsu:Created>2003-07-16T01:24:32</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
...
</S11:Header>
...
</S11:Envelope>
Los parámetros de Hash Password Support y Token Assertion en Metro 1.2 explican muy bien cómo se ve un UsernameToken con Digest Password:
Compatibilidad con contraseña de resumen
El perfil de token de nombre de usuario de WSS 1.1 permite enviar las contraseñas de resumen en un
wsse:UsernameTokende un mensaje SOAP. Se incluyen dos elementos opcionales más enwsse:UsernameTokenen este caso:wsse:Nonceywsse:Created. Un nonce es un valor aleatorio que el remitente crea para incluir en cada nombre de usuario que ha enviado. Se agrega un tiempo de creación para combinar nonces a un período de "actualización". El Compendio de contraseñas en este caso se calcula como:
Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )Así es como se ve un UsernameToken con Digest Password:
<wsse:UsernameToken wsu:Id="uuid_faf0159a-6b13-4139-a6da-cb7b4100c10c"> <wsse:Username>Alice</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">6S3P2EWNP3lQf+9VC3emNoT57oQ=</wsse:Password> <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">YF6j8V/CAqi+1nRsGLRbuZhi</wsse:Nonce> <wsu:Created>2008-04-28T10:02:11Z</wsu:Created> </wsse:UsernameToken>
Marque este (la contraseña debe ser contraseña):
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-6138db82-5a4c-4bf7-915f-af7a10d9ae96">
<wsse:Username>user</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">CBb7a2itQDgxVkqYnFtggUxtuqk=</wsse:Password>
<wsse:Nonce>5ABcqPZWb6ImI2E6tob8MQ==</wsse:Nonce>
<wsu:Created>2010-06-08T07:26:50Z</wsu:Created>
</wsse:UsernameToken>
Puede ser que esta publicación ( Secure Web JAX-WS UsernameToken Web Service con firma, cifrado y TLS (SSL) ) proporcione más información. Como mencionaron "Recuerde, a menos que el texto de la contraseña o la contraseña digerida se envíe en un canal seguro o el token esté cifrado, ni el resumen de la contraseña ni la contraseña de texto simple no ofrecen una seguridad adicional real".