Hi Colm -

Thanks for trying to reproduce.
Starting to get concerned about a regression....

I see that you are using localhost - that will definitely present problems
for Set-Cookie with some browsers.
I know that Chrome will not accept it for sure.

Can you switch to a full domain name?
I usually just map localhost to www.local.com in my /etc/hosts file.

You will also need to make sure to set the whitelist for the domain name.

thanks,

--larry


On Mon, Feb 19, 2018 at 12: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
>

Reply via email to