KnoxSSO service (WebSSOResource) uses it to redirect to the originally
requested resource.

The KnoxSSO service assumes that by the time the request gets to it that
authentication/federation of the enduser has been done, that the enduser is
authorized to use knoxsso and that the identity assertion has mapped it to
whatever the effective user should be.

Therefore, the KnoxSSO service can then extract the PrimaryPrincipal from
the normalized Java Subject, create the JWT representation of the
authentication event and set-cookie.
It then redirects the user agent to the originally requested resource where
the browser should present the cookie.

In this case, SSOCookieProvider will be then looking for the cookie and
will redirect back to KnoxSSO if it is not present.

On Mon, Feb 19, 2018 at 1:15 PM, Colm O hEigeartaigh <cohei...@apache.org>
wrote:

> OK I'll check it. A question though - where is the redirection via
> originalUrl supposed to take place? From the source I can see "originalUrl"
> is referenced in:
>
> gateway-applications/src/main/resources/applications/
> knoxauth/app/js/knoxauth.js
> gateway-applications/src/main/resources/applications/
> knoxauth/app/redirecting.jsp
>
> However, I'm not using the knoxauth application (with pac4j)?
>
> Colm.
>
> On Mon, Feb 19, 2018 at 6:04 PM, larry mccay <lmc...@apache.org> wrote:
>
>> 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?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
>>>
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Reply via email to