The documentation describing how to connect to a kerberos secured endpoint shows the following:
curl -i --negotiate -u : \"http://:/w
Answer is:
[
{
"operation": "shift",
"spec": {
"scheduler": {
"schedulerInfo": {
"usedCapacity": "root",
"queues": {
"queue": {
"*": {
"@usedCapacity": "@queueName"
}
}
}
}
}
}
},
{
"operation": "shift",
"spec": {
"*": "&UsedCapacity"
}
}
]
Being a once-in-a-while-contributor to curl
in that area. Here is what you need to know:
curl(1)
itself knows nothing about Kerberos and will not interact neither with your credential cache nor your keytab file. It will delegate all calls to a GSS-API implementation which will do the magic for you. What magic depends on the library, Heimdal and MIT Kerberos.
Based on your question, I assume that you have little knowledge about Kerberos and want simply automate API calls to a REST endpoints secured by SPNEGO.
Here is what you need to do:
curl
7.38.0 against MIT Kerberoscurl --version
mentioning GSS-API and SPNEGO and with ldd
linked against your MIT Kerberos version.ktutil
or mskutil
kinit -k -t <path-to-keytab> <principal-from-keytab>
klist
that you have a ticket cacheEnvironment is now ready to go:
KRB5CCNAME=<some-non-default-path>
KRB5_CLIENT_KTNAME=<path-to-keytab>
curl --negotiate -u : <URL>
MIT Kerberos will detect that both environment variables are set, inspect them, automatically obtain a TGT with your keytab, request a service ticket and pass to curl
. You are done.
Note: this will not work with Heimdal.
Check curl version
$ curl -V
- It should support the feature "GSS-Negotiate"
Login using kinit
$ kinit <user-id>
Use curl
$ curl --negotiate -u : -b ~/cookiejar.txt -c ~/cookiejar.txt http://localhost:14000/webhdfs/v1/?op=liststatus
"--negotiate" option enables SPNEGO
"-u" option is required but ignored (the principle specified during kinit is used)
"-b" & "-c" options are used to store and send http cookies.