Hi, Logs look good in pac4j. Redirecting to the identity provider and then coming back to the gateway. Maybe the user identity is not properly created...
Can you turn on DEBUG logs on org.pac4j and org.apache.knox.gateway.pac4j? Thanks. Best regards, Jérôme On Mon, Feb 19, 2018 at 6:49 PM, Colm O hEigeartaigh <cohei...@apache.org> wrote: > I can reproduce the issue with Google. From the logs I see the following: > > 2018-02-19 17:21:58,484 DEBUG session.KnoxSessionStore > (KnoxSessionStore.java:get(91)) - Get from session: pac4jRequestedUrl = > https://localhost:8443/gateway/knoxssopac4j/api/v1/ > websso?originalUrl=https://localhost:8443/gateway/ > sandbox-ssopac4j/webhdfs/v1/data/LICENSE.txt?op=OPEN > 2018-02-19 17:21:58,485 DEBUG session.KnoxSessionStore > (KnoxSessionStore.java:set(107)) - Save in session: pac4jRequestedUrl = > null > 2018-02-19 17:21:58,485 DEBUG engine.DefaultCallbackLogic > (DefaultCallbackLogic.java:redirectToOriginallyRequestedUrl(137)) - > redirectUrl: https://localhost:8443/gateway/knoxssopac4j/api/v1/ > websso?originalUrl=https://localhost:8443/gateway/ > sandbox-ssopac4j/webhdfs/v1/data/LICENSE.txt?op=OPEN > 2018-02-19 17:21:58,488 DEBUG knox.gateway (GatewayFilter.java:doFilter(119)) > - Received request: GET /api/v1/websso > > It is getting an access token correctly and trying to redirect back to the > original URL. However from the logs above it seems to never hit the > original URL but instead hits the "redirectUrl". Is some parsing supposed > to take place to extract "originalUrl" from the "pac4jRequestedUrl" > parameter and redirect to this instead? > > Colm. > > On Mon, Feb 19, 2018 at 4:16 PM, larry mccay <lmc...@apache.org> wrote: > >> No, the hadoop-jwt cookie is for KnoxSSO and the SSOCookieProvider. >> If it isn't being set, it could be that it isn't getting past the pac4j >> federation provider to the KnoxSSO service itself because there is a >> redirect from the pac4j provider or the Set-Cookie just isn't being >> accepted by the browser. >> >> The audit log does seem to be getting a redirect from pac4j. >> >> I haven't seen any examples of it working AAD - so we are in unchartered >> waters here. >> >> @Jerome - any insights? >> >> On Mon, Feb 19, 2018 at 2:04 AM, Nisha Menon <nisha.meno...@gmail.com> >> wrote: >> >>> 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 >>> >> >> > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
