Hi Jerome/Sandeep, Azure AD does support query parameters in the Reply URL for Azure app registration, whereas in v2 with microsoft app registration portal, it does not. However, even in the first case where it allows the parameters during configuration, it does not honor them by sending it back with the response.. hence the issue!
I also came across a post ( https://groups.google.com/forum/#!topic/pac4j-users/-GGzLrONSOI ) where the user tries to customize the call in such a way "/callback */client_name=AzureAD/*" as opposed to " /callback*?client_name=AzureAD*". Can we try this quickly for KNOX? Is it possible to achieve this? Regards, Nisha On Mon, Feb 26, 2018 at 7:43 PM, Sandeep Moré <moresand...@gmail.com> wrote: > Hello Jérôme > You are right about the client_name and pac4JCallback parameters. > I do not think this is because of misconfiguration, the issue in this case > is that Azure AD does not support query params in the callback URLs. > > Best, > Sandeep > > On Mon, Feb 26, 2018 at 1:42 AM, Jérôme LELEU <lel...@gmail.com> wrote: > >> Hi, >> >> The callback URL sent by the IdP does not have the client_name parameter, >> nor the pac4jCallback parameter (the parameter has changed between >> versions). >> >> So the callback is not properly detected and an authentication is tried >> over and over again. >> >> So I guess there is a misconfiguration on the IdP side at the callback >> URL level. >> >> Thanks. >> Best regards, >> Jérôme >> >> >> On Wed, Feb 21, 2018 at 4:45 AM, Nisha Menon <nisha.meno...@gmail.com> >> wrote: >> >>> Hi Jerome. >>> >>> PFA the logs after enabling the pac4j logs. Hope this helps. >>> >>> Regards >>> Nisha >>> >>> On Tue, Feb 20, 2018 at 7:50 PM, Jérôme LELEU <lel...@gmail.com> wrote: >>> >>>> 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.pa >>>> c4j? >>>> >>>> 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?or >>>>> iginalUrl=https://localhost:8443/gateway/sandbox-ssopac4j/we >>>>> bhdfs/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:84 >>>>> 43/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 >>>>> >>>> >>>> >>> >>> >>> >> >
