How to use SPNEGO negotiation with Curl

1. First we need to check that we have an SPNEGO compatible Curl installed:

$ curl -V
curl 7.81.0 (x86_64-w64-mingw32) libcurl/7.81.0 OpenSSL/1.1.1m (Schannel) zlib/1.2.11 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.1 libssh2/1.10.0 nghttp2/1.46.0
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI TLS-SRP zstd

Here we can see that the SPNEGO feature is available

2. Next we need to create a credentials cache for Curl to use

kinit <username>
Password for <username>@<domain.com>: <password>

Here we create a “authentication token” and put it in a credentials cache för Curl, and any other program ie. SoapUI and others, to use. ‘username’ is the name of the user. This can be omitted, and if so the default user and domain (user that runs the command) will be used instead. The ‘kinit’ command will ask for the password associated with the user. After this has been inputed the token is created

3. After that we run Curl with the following options:

curl --negotiate -u : https://a-spnego-protected-site/data-i-want-to-access

–negotiate will trigger SPNEGO behaviour
-u is needed but is left blank. On some sites though I have had to put <domain\user> to get it to work
: should point to the SPNEGO protected resource we want to access
Curl will now use the token in the credentials cache to authenticate against the web resource

Troubleshooting commands:

klist - lists all current tokens with the expiry timestamps in the cache
kdestroy - remove a ticket from the credentials cache

Tested with Curl v7.81.0 in GitBash on a Windows 10 with Java 1.8.0_301

Mule 4: Set the output encoding on a flat file transformation

Every now and then you are working on a UTF-8 system and you have to deliver a flat file (or any other string) to a ISO-8859-1 system, as an example. To achive this we need to tell Mule that we want the result in ISO-8859-1 and not the default UTF-8.

This can be solved like this:

%dw 2.0
output application/flatfile encoding="ISO-8859-1"

Without the “encoding=ISO-8859-1” we would get the default UTF-8 encoding. This works of course for many other encoding-transformations

Tested on Mule 4.3, Anypoint Studio 7.11 on Windows 10

Mule flat file mapping: “com.mulesoft.flatfile.lexical.WriteException – effective length * is greater than * for component…” – alternative solution

This falls under the category “strange error messages” in Mule. Normaly you would think that the data you send is bigger than the longest allowed value, but in my case it was because I was trying to map a value from an array without setting a index

Tested in Anypoint Studio 7.11.1 and Mule 4.3