In our use case, our service needs to interact with tomcat server which accepts only SPNEGO token for Kerberos. Users interacting with service will delegate their gss credential after kerberos authentication. Our service needs to use the delegated user credential and authenticate again with tomcat server via curl and further delegate the user credential. Service also has other ways of obtaining gss credential via spn-keytab and service credential cache. Now, we need a way to specify gss credential in curl options to satisfy these cases. With this feature, curl can be used by a service to impersonate multiple users in kerberos mode.
curl relies on MIT Kerberos to generate SPNEGO token. By default, MIT Kerberos will use KRB5 mechanism with default KRB5 credential (set via default credential cache or KRB5CCNAME env var). In CURL 7.37.1, No mechanism OID was being passed to MIT Kerberos. MIT Kerberos used to choose KRB5 mech type and return KRB5 token from default credential cache and curl used to convert it into SPNEGO token using fbopenssl. We added new curl option to specify gss credential and it worked fine. I am already working on privately adding this enhancement in curl for now but facing a blocker. In CURL 7.68, curl passes SPNEGO mech type to MIT Kerberos and MIT Kerberos returns SPNEGO token with default gss credential. We cannot use SPENGO mech type with krb5 gss credential as MIT Kerberos will reject credential not matching the mech type. We have to make mechanism type configurable and use KRB5 mech type and MIT Kerberos will return KRB5 token. Then we need to convert this into SPNEGO token like old curl. For Conversion of KRB5 token into SPNEGO token, i am looking for some standard API rather than writing my own. On Thu, Jan 14, 2021 at 6:28 PM Daniel Stenberg <dan...@haxx.se> wrote: > On Tue, 5 Jan 2021, Vipul Mehta via curl-library wrote: > > Thanks for considering contributing to the project! > > > We are working on adding the support for GSS credential and Credential > cache > > in curl version 7.68 and once done, we would like to merge this to curl > main > > repo so that in future we don't face such compatibility issues again. > > > > What are the prerequisites for such merge ? > > - A pull request on GitHub > - Docs and test cases included > - Green CI builds (except for the flaky ones) > - Approvied review > > > Will this feature be acceptable ? > > I'm not I understand what exactly it does and why we need it. I think it > would > help if you clarified exactly how it makes libcurl better and for what use > cases we need/want to use this feature. > > > Is this feature already on the roadmap ? > > Not in mine. > > -- > > / daniel.haxx.se > | Commercial curl support up to 24x7 is available! > | Private help, bug fixes, support, ports, new features > | https://www.wolfssl.com/contact/ > -- Regards, Vipul
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
