If you want to test web services against a Kerberos server, or if you have to kerberize an existing GUI application, you can now use the reverse proxy “NegotiateProxy” free of charge…
In order to be able to use Kerberos with the utmost efficiency in a corporation, the GUI applications need to be “kerberized”. This means the following: All client applications must be able to request Kerberos tickets from the Windows Domain Controller and pass them on to the service backend. In the specialized environment of web services, Kerberos is deployed on the base of the standard SPNEGO, i.e. a Kerberos ticket is transferred in the form of a HTTP header to the service backend (“Authorization: Negotiate <Base64-encoded Kerberos Ticket>”).
Classical test tools like soapUI and JMeter support Kerberos/SPNEGO by default now. However, you need to conduct some configurations at the client which require admin rights in certain cases since the kerberized service requests do not happen in an entirely transparent way.
If you have to test web services against a Kerberos server, or if you have to kerberize an existing GUI application, you should use a Kerberized Reverse Proxy which takes the application's service requests, requests Kerberos tickets from the Domain Controller and transfers them automatically as SPNEGO conform HTTP header to the Backend. The tool “NegotiateProxy” is such a Reverse Proxy and is now at your disposal!
NegotiateProxy is a Reverse Proxy which conducts the SPNEGO/Kerberos communication without the user or application taking notice. This tool is applied in cases in which web services have to be set apart from kerberized service backends while the client applications themselves are not able to use Kerberos.
The standards SPNEGO, GSS-API and Kerberos respectively of the RfCs 4559, 2478, 4178 can be extracted from this link.
NegotiateProxy extends a non-Kerberized application with the feature “SPNEGO/Kerberos”: The proxy is started on the client computer and put on the kerberized backend provided with a forwarding/transmission order. The (non-kerberized) client application will then request its web services against the local reverse proxy and not against the actual service backend. The proxy will operate as a “Man-in-the-Middle” and take over the entire handling of the Kerberos tickets and SPNEGO header.
| | | |
| | | |
+------+---- App. | | App. |
|local | |Negotiate Kerberized | ^ |
|host | | Proxy Service | | |
+------+-->6268---|---------> Network --------> |---443 |
| | [SSL] SSL | |
| | [X.509] X.509 | |
In contrast to different proxy solutions, the NegotiateProxy does not have to be installed and can simply be selected via the prompt.