[jboss-jira] [JBoss JIRA] Created: (SECURITY-572) Support for situation when first OID is Kerberos OID instead of SPNEGO OID
Support for situation when first OID is Kerberos OID instead of SPNEGO OID
--------------------------------------------------------------------------
Key: SECURITY-572
URL: https://issues.jboss.org/browse/SECURITY-572
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Negotiation
Affects Versions: Negotiation_2.0.3.GA
Environment: JBoss EPP 5.1.GA with SPNEGO support, JBoss Negotiation 2.0.3,
commons-http-client 3.1 used as HTTP client
Reporter: Marek Posolda
Assignee: Darran Lofthouse
Fix For: Negotiation_2.0.4
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...
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira