Hello Larry, hadoop-jwt cookie is not set. Isnt this for JWT provider? In SSO provider with pac4j, I can see cookies like: pac4j.session.pac4jRequestedUrl, pac4j.session.oidcStateAttribute, pac4j.session.oidcNonceAttribute etc.
IP address and hostnames are mapped, else the *basic auth* also would have failed. My issue is only when I use pac4j with Oidc client and Azure AD. On Fri, Feb 16, 2018 at 10:11 PM, larry mccay <lmc...@apache.org> wrote: > It looks like you may be using ip addresses for your Knox URLs - to > webhdfs. > In order to rule out cookie related issue can you do a couple things: > > 1. check whether a cookie called hadoop-jwt is actually set in your browser > 2. if not, you may want to set an actual domain in your /etc/hosts or > something that you can reference - I use www.local.com to map to localhost > > I think that ip address should work for this case actually but there are > differences in browsers that might not let it. > Also, if you had another service on another ip address, the browser would > not present the cookie - so this is good to be aware of anyway. > > On Fri, Feb 16, 2018 at 8:55 AM, Sandeep Moré <moresand...@gmail.com> > wrote: > >> Hello Nisha, >> Can you share details of "mycluster" topology ? also, can you turn up the >> logs to debug and share them along with the audit log that would help us to >> understand the problem better. >> >> Best, >> Sandeep >> >> On Fri, Feb 16, 2018 at 3:16 AM, Nisha Menon <nisha.meno...@gmail.com> >> wrote: >> >>> Hello, >>> >>> I have setup KNOX to connect with Azure AD using pac4j. >>> >>> However, after the authentication at Azure login page, it gets into an >>> infinite loop and does not give back the original REST call response. >>> >>> *Details:* >>> >>> 1. I try to access the original URL eg: >>> *https://x.x.2.3:8442/gateway/mycluster/webhdfs/v1/user?op=LISTSTATUS >>> <https://x.x.2.3:8442/gateway/mycluster/webhdfs/v1/user?op=LISTSTATUS>* >>> >>> 2. It redirects to *https://**login.microsoftonline.com >>> <http://login.microsoftonline.com/>* and asks for credentials. >>> >>> 3. After successful login at Azure login page, it redirects to >>> *http://x.x.2.3:8442/gateway/knoxsso/api/v1/websso >>> <http://x.x.2.3:8442/gateway/knoxsso/api/v1/websso>* with code, session >>> and state variables passed as below: >>> >>> *https://x.x.2.3:8442/gateway/knoxsso/api/v1/websso?code=AQABAAIAAABHh4k***********************LFFm7C9cIShE7nggAA&state=5dzTZBYhEVDBrA*****************GZRNfANGb5ls&session_state=42f2447b-621***********790eaa2d18 >>> <https://x.x.2.3:8442/gateway/knoxsso/api/v1/websso?code=AQABAAIAAABHh4k***********************LFFm7C9cIShE7nggAA&state=5dzTZBYhEVDBrA*****************GZRNfANGb5ls&session_state=42f2447b-621***********790eaa2d18>* >>> >>> 2. Following this call, it *again *calls the *login.microsoftonline.com >>> <http://login.microsoftonline.com/>* like below: >>> >>> *https://login.microsoftonline.com/f82969ba-b***********c1d0557a/oauth2/authorize?response_type=code&client_id=385*******3-a4bdceaa34&redirect_uri=https%3A%2F%2Fx.x.2.3%3A8442%2Fgateway%2Fknoxsso%2Fapi%2Fv1%2Fwebsso%3Fpac4jCallback%3Dtrue%26client_name%3DOidcClient≻ope=openid+profile+email&state=5dzTZBYhEVDBrAInao9VHDRd33uiRp-GZRNfANGb5ls&nonce=BvCUroM7_aKFjmbLYxaxbS0Mq9SJ8If0CUpITEGB-bw >>> <https://login.microsoftonline.com/f82969ba-b***********c1d0557a/oauth2/authorize?response_type=code&client_id=385*******3-a4bdceaa34&redirect_uri=https%3A%2F%2Fx.x.2.3%3A8442%2Fgateway%2Fknoxsso%2Fapi%2Fv1%2Fwebsso%3Fpac4jCallback%3Dtrue%26client_name%3DOidcClient%E2%89%BBope=openid+profile+email&state=5dzTZBYhEVDBrAInao9VHDRd33uiRp-GZRNfANGb5ls&nonce=BvCUroM7_aKFjmbLYxaxbS0Mq9SJ8If0CUpITEGB-bw>* >>> >>> After this, step 1 and 2 alternate several times and finally lands up in >>> "ERR_TOO_MANY_REDIRECTS"!!! >>> >>> This is my knoxsso.xml: >>> >>> >>> 1. <topology> >>> 2. <gateway> >>> 3. <provider> >>> 4. <role>webappsec</role> >>> 5. <name>WebAppSec</name> >>> 6. <enabled>true</enabled> >>> 7. >>> <param><name>xframe.options.enabled</name><value>true</value></param> >>> 8. </provider> >>> 9. <provider> >>> 10. <role>federation</role> >>> 11. <name>pac4j</name> >>> 12. <enabled>true</enabled> >>> 13. <param> >>> 14. <name>pac4j.callbackUrl</name> >>> 15. >>> <value>https://x.x.2.3:8442/gateway/knoxsso/api/v1/websso</value> >>> 16. </param> >>> 17. <param> >>> 18. <name>clientName</name> >>> 19. <value>OidcClient</value> >>> 20. </param> >>> 21. <param> >>> 22. <name>oidc.id</name> >>> 23. <value>385c2bc*****************2695eaa34</value> >>> 24. </param> >>> 25. <param> >>> 26. <name>oidc.secret</name> >>> 27. >>> <value>Y30wOwM88BY************vYmPp8KMyDY2W+o=</value> >>> 28. </param> >>> 29. <param> >>> 30. <name>oidc.discoveryUri</name> >>> 31. >>> <value>https://login.microsoftonline.com/f82969***********1d0557a/.well-known/openid-configuration</value> >>> 32. </param> >>> 33. </provider> >>> 34. <provider> >>> 35. <role>identity-assertion</role> >>> 36. <name>Default</name> >>> 37. <enabled>true</enabled> >>> 38. </provider> >>> 39. </gateway> >>> 40. <application> >>> 41. <name>knoxauth</name> >>> 42. </application> >>> 43. <service> >>> 44. <role>KNOXSSO</role> >>> 45. <param> >>> 46. <name>knoxsso.cookie.secure.only</name> >>> 47. <value>false</value> >>> 48. </param> >>> 49. <param> >>> 50. <name>knoxsso.token.ttl</name> >>> 51. <value>30000</value> >>> 52. </param> >>> 53. <param> >>> 54. <name>knoxsso.redirect.whitelist.regex</name> >>> 55. >>> <value>^https?:\/\/(dap-e0|x\.x\.2\.3|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*$/value> >>> 56. </param> >>> 57. </service> >>> 58. </topology> >>> >>> I tried using response_type "id_token", enabling nonces, knoxsso.secure >>> to true, preferredJwsAlgorithm as RS256 etc. Nothing helps. >>> >>> gateway-audit.log when redirection error starts: >>> >>> >>> 1. 18/02/15 12:38:02 >>> ||7a66725e-6d9d-4ef5-9017-2b52d7d15ccf|audit|KNOXSSO||||access|uri|/gateway/knoxsso/api/v1/websso?code=AQABAAIAAABHh4kmS_a**********************_WuZRkgVKneLpp83HnSlcntEbAmAgAA&state=0n7h1Y2LTz_**************99P92pZonRN-c&session_state=f0ac55a1-4***********-53e3e126b40e|success|Response >>> status: 302 >>> >>> It clearly shows Response status as "302" and not "200". This leads to >>> redirection! >>> >>> What could I be missing here? Any pointers will be greatly appreciated. >>> Regards >>> Nisha >>> >>> >> > Regards Nisha
