Support for situation when first OID is Kerberos OID instead of SPNEGO OID

Currently first byte of SPNEGO token is used to recognize if it's new token NegTokenInit and another 3 bytes are used to recognized length. From byte 5 is starting sequence for recognizing OID. Currently NegotiationAuthenticator is able to handle situations where this OID is SPNEGO OID (1.3.6.1.5.5.2) but it's not able to correctly handle situations where first OID is Kerberos OID (1.2.840.113554.1.2.2).

Problem is that if Kerberos is used, then the rest of sequence format is different then for SPNEGO and IOException is thrown in method NegTokenInitDecoder.decodeNegTokenInitSequence because the sequence type is not expected value (any of 0xa0, 0xa1, 0xa2, 0xa3).

I think that support for Kerberos OID is not critical and I am not sure if it's really the issue, but guys here https://issues.apache.org/jira/browse/HTTPCLIENT-523 are saying that it's working correctly with IIS but not with JBoss Negotiation.

For simulating of situation can be used commons-httpclient3 with integration of NegotiateScheme: http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/trunk/src/contrib/org/apache/commons/httpclient/contrib/auth/

Or you can simulate it by sending this Negotiate token in HTTP header:

Authorization : Negotiate YIID7QYJKoZIhvcSAQICAQBuggPcMIID2KADAgEFoQMCAQ6iBwMFAAAAAACjggEEYYIBADCB/aADAgEFoQ8bDUxPQ0FMLk5FVFdPUkuiJzAloAMCAQChHjAcGwRIVFRQGxRzZXJ2ZXIubG9jYWwubmV0d29ya6OBuzCBuKADAgEDoQMCAQOigasEgajWrIRyQlCHtxXO//EMI/6C9zBChS00QtgZLctUa0qjb14RZFFj5pyruAB7SrqnxuD7JROJpwsVZG7FDpFu47Y3ZXyWjq8C1px+V4CULGgOt3Aufyh8DVRGeuhxYQ17APR5pC418Wo/u/VIJvLco7VZaAlGEF0xyJ8thtBM8Oz88urPpVxOl+7mUd2XirkqReL5ITdsEOjnZ4Q8duYKDPq9GdVcvf7MFyikggK5MIICtaADAgEBooICrASCAqjngVyeX24XzPtoMsnO0W2DoiX+SfpshcbZOVN0ne98Zxhnq3gxxiHiiI3voWTqtAiXe9E/Ti+wPuFI1g4jXsOjY8V4GGfDxihxGSMa9vu45JvLr+MPL40EwmFaD6fRpU+DA80ZhS+1THhTKT2w28pJS45fgSM2igmXQYk0hfv/Q7xIYBmNJXMZ2ZgyY8dek5dflg9zjuZetR6RSYJtu7Q+c/w3t/yHYLtcrz98aD+Q4EjBtf4I3EpP+c5NSkpouSvRy8u4yPNgOyvM8CdXuABveVdl+/DX100ucJc9uXAL+lPMdk+YMo8rAoEWae3km5LDfd3JncPB50OKwjNzejvi5e+5OYG17TpTx88sGMl0JLQ5mgrUBMPMG/c2sje4mhmTa8nO8SdqP6Fa1HVYPZNgDskSvTQzM0zsLRU0tyuge41hB8J6AOje1rGvpLBKMdMbXqnD08aC0N1qL1b5TmNk2jcWyJaGAi1pxzyNDwFTL5LUr7e+bIHrX2nd3g328pdDfZCBiqvrInXR+7phnKYinit22O4ktQQRuS9bybZR+ECAVrnCXspPieIvPLZYrzEDgp3NXYlUUzyWuNBN/obXAHiXhE0LMtnDvSs/MQYHTjGAahoKVjxNWDSmRylGD49dAI/N+cNnB/1NruSTLd5voahGYrnDmoouWafa4oaARZqq48lSAgaMhfPoMfYaBSWS9mWYltBEsTUAQO3sNg0Sx0d0jtQzQG/37mxKCF5F/rAeeI5NQcRrXV1RZzkY7UPyaiIwelt/ZOo2tJqgkSIKQwPBlH/GGlRvrCse3f2Eg/FoSKUMTHkjl433BiG4J9+5Isgchgl6XfolW4d7b5Ztqg0zi+k0ydTzpeK1h9mYbJ1ML2rdlHTXNEnF0fmwz+4SGk09bG/Rqw==

Another thing is handling of IOException, which is not logged anywhere, but I will create another JIRA issue for it.