No, I believe Jerome was expecting this to work. Perhaps, this is something that we won't get until we upgrade pac4j dependency. That would explain why it isn't in the docs.
On Wed, Oct 4, 2017 at 10:34 AM, N. Vidiadakis <[email protected]> wrote: > Hey Larry, > > To be honest, I tried adding the property in the knoxsso.xml topology file > but without success. I guess you mean to edit directly the pac4j provider? > > KR, > Nick > > > On Wed, Oct 4, 2017 at 5:30 PM, larry mccay <[email protected]> wrote: > >> Hi Jerome - >> >> Thank you for the clarification - I didn't see any mention of that >> property in the docs! >> I will check again and add it if needed. >> >> @Nick - you can use the property oidc.clientAuthenticationMethod inside >> the pac4j provider to tell it which to choose rather than having to provide >> a new metadata file. >> Give that a shot. >> >> thanks, >> >> --larry >> >> On Wed, Oct 4, 2017 at 2:25 AM, Jérôme LELEU <[email protected]> wrote: >> >>> Hi, >>> >>> Sorry if I was not clear. >>> >>> But indeed, pac4j will select the first authentication method defined in >>> your OpenID Connect server metadata if you haven't defined any >>> authentication method in the properties. This is nonetheless something you >>> can do using this property: oidc.clientAuthenticationMethod >>> >>> Thanks. >>> Best regards, >>> Jérôme >>> >>> >>> On Tue, Oct 3, 2017 at 4:38 PM, larry mccay <[email protected]> wrote: >>> >>>> Hi Nick - >>>> >>>> No, I believe that Jerome is saying that pac4j does not support >>>> private_key_jwt and I don't believe that we have any provider that we could >>>> trick into just doing that. You would need to write a custom provider. >>>> >>>> It seems to me that he is indicating that the metadata available from >>>> your discovery url is what is used to construct the oidc client. Perhaps >>>> you can create another metadata file that you can point the discovery url >>>> to that doesn't include the private_key_jwt in the following: >>>> >>>> "registration_endpoint":"https://aegle-keycloak.exodussa.co >>>> m/auth/realms/AEGLE/clients-registrations/openid-connect", >>>> "token_endpoint_auth_methods_supported":[ >>>> "private_key_jwt", >>>> "client_secret_basic", >>>> "client_secret_post" >>>> ], >>>> >>>> I would think that pac4j would skip one that it doesn't support but you >>>> can give it a shot to see what happens. Another possibility would be to >>>> reorder them so that it finds client_secret_basic or post before jwt. >>>> >>>> Once you get past this issue, you are probably going to need to >>>> configure the whitelist properly so that the originalUrl matches otherwise >>>> you will get a 400 bad request. This is to protect you from getting >>>> redirected to phishing pages. >>>> >>>> HTH, >>>> >>>> --larry >>>> >>>> On Tue, Oct 3, 2017 at 9:10 AM, N. Vidiadakis <[email protected]> >>>> wrote: >>>> >>>>> Hello again, >>>>> >>>>> Lets try to simplify the case and remove the login process with the >>>>> redirection. Can KNOX be configured to act as a token bearer only client? >>>>> So that no authentication is done from the user, just use a bearer only >>>>> JWT >>>>> token that will get validated from the Idp. >>>>> >>>>> KR, >>>>> Nick Vidiadakis >>>>> >>>>> >>>>> On Tue, Oct 3, 2017 at 11:18 AM, N. Vidiadakis <[email protected]> >>>>> wrote: >>>>> >>>>>> Hello to all again, >>>>>> >>>>>> This is what happens during the redirection process in the Idp (this >>>>>> is the POST request with authentication), as I've recorded it using >>>>>> developer tools of Chrome: >>>>>> >>>>>> Request URL:https://aegle-keycloak.exodussa.com/auth/realms/AEGLE/lo >>>>>> gin-actions/authenticate?code=GURA9HtMgD3qLRMQ5VWB4pIyeVbhiZ >>>>>> aTyE-FtmeGvIM.475fff9a-dce5-42ce-86d9-9433941f919d&execution >>>>>> =7e0fa916-c58b-4a07-8200-f822793c5ecd >>>>>> Request Method:POST >>>>>> Status Code:302 Found >>>>>> Remote Address:83.212.114.145:443 >>>>>> Referrer Policy:no-referrer-when-downgrade >>>>>> Response Headers >>>>>> view parsed >>>>>> HTTP/1.1 302 Found >>>>>> Server: nginx/1.9.15 >>>>>> Date: Tue, 03 Oct 2017 08:02:27 GMT >>>>>> Content-Length: 0 >>>>>> Connection: keep-alive >>>>>> Cache-Control: no-store, must-revalidate, max-age=0 >>>>>> X-Powered-By: Undertow/1 >>>>>> Set-Cookie: KEYCLOAK_IDENTITY=eyJhbGciOiJS >>>>>> UzI1NiJ9.eyJqdGkiOiIzOTkyMWM3Yi1lMzBiLTRjZGItOWM3MS1mZTljYTE >>>>>> 1Y2NhZmQiLCJleHAiOjE1MDcwNTM3NDcsIm5iZiI6MCwiaWF0IjoxNTA3MDE >>>>>> 3NzQ3LCJpc3MiOiJodHRwczovL2FlZ2xlLWtleWNsb2FrLmV4b2R1c3NhLmN >>>>>> vbS9hdXRoL3JlYWxtcy9BRUdMRSIsInN1YiI6IjM3ODdhNDQyLTBiN2QtNGJ >>>>>> lYi05YjRiLWQzNTBjYTEwZDNhOCIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9 >>>>>> zdGF0ZSI6ImIzOTNjNzVhLWI4MTktNDM0ZS1iYjRlLTUyODllM2NjZWQyNCI >>>>>> sInJlc291cmNlX2FjY2VzcyI6e319.UrefWhhVEQQoI5jVjd71IcK7-4P27M >>>>>> shA54K3o7PWpJ-9xzhD156fG1_r8L6cflTkeiSLyHU173SSIWkfo69Xi-aQO >>>>>> PVhtWF3DR9UCPnQu0Nk5OSXFi5g_PwNCiUQsK_7bPVa8M5fNuxv6JbuoZB7j >>>>>> v-PFpsL4lO1gQs8kxPVW-ig1KBcpJYuwaoxESBrq5pwov82_ipQijWUVC_5P >>>>>> zui8eT58e-ubAZBuUZjyfyZXqYFdcgvaFw-WOXEnZUubHUfOFKavlVwfBLAI >>>>>> DzIjGJJGMghVb7KjK4abx2mfQHl6H_qTbEqh1JyFHebuluRB99sYWk82pPzZ2AVP_ejF7Y8g; >>>>>> Version=1; Path=/auth/realms/AEGLE; HttpOnly >>>>>> Set-Cookie: KEYCLOAK_SESSION=AEGLE/3787a44 >>>>>> 2-0b7d-4beb-9b4b-d350ca10d3a8/b393c75a-b819-434e-bb4e-5289e3cced24; >>>>>> Version=1; Expires=Tue, 03-Oct-2017 18:02:27 GMT; Max-Age=36000; >>>>>> Path=/auth/realms/AEGLE >>>>>> P3P: CP="This is not a P3P policy!" >>>>>> Location: https://83.212.114.145:8443/ga >>>>>> teway/knoxsso/api/v1/websso?pac4jCallback=true&client_name=O >>>>>> idcClient&state=ll1wYF2tjnjL4FQohTNdjz095OtXdYGUa8b4qsU9sE4& >>>>>> code=GURA9HtMgD3qLRMQ5VWB4pIyeVbhiZaTyE-FtmeGvIM.475fff9a-dc >>>>>> e5-42ce-86d9-9433941f919d >>>>>> Request Headers >>>>>> Accept:text/html,application/xhtml+xml,application/xml;q=0.9 >>>>>> ,image/webp,image/apng,*/*;q=0.8 >>>>>> Accept-Encoding:gzip, deflate, br >>>>>> Accept-Language:en-US,en;q=0.8,el;q=0.6 >>>>>> Cache-Control:max-age=0 >>>>>> Connection:keep-alive >>>>>> Content-Length:52 >>>>>> Content-Type:application/x-www-form-urlencoded >>>>>> Cookie:KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQ3NWZmZjlhL >>>>>> WRjZTUtNDJjZS04NmQ5LTk0MzM5NDFmOTE5ZCIsImNpZCI6ImFlZ2xlX2tub >>>>>> 3giLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovLzgzL >>>>>> jIxMi4xMTQuMTQ1Ojg0NDMvZ2F0ZXdheS9rbm94c3NvL2FwaS92MS93ZWJzc >>>>>> 28_cGFjNGpDYWxsYmFjaz10cnVlJmNsaWVudF9uYW1lPU9pZGNDbGllbnQiL >>>>>> CJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiN >>>>>> 2Q3ZTVmNjQtZGVhZi00NDA3LTljZDktMGI2ZGVhOGM5MzQ1IiwiYXV0aF90e >>>>>> XBlIjoiY29kZSIsInNjb3BlIjoib3BlbmlkIiwiaXNzIjoiaHR0cHM6Ly9hZ >>>>>> WdsZS1rZXljbG9hay5leG9kdXNzYS5jb20vYXV0aC9yZWFsbXMvQUVHTEUiL >>>>>> CJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzO >>>>>> i8vODMuMjEyLjExNC4xNDU6ODQ0My9nYXRld2F5L2tub3hzc28vYXBpL3YxL >>>>>> 3dlYnNzbz9wYWM0akNhbGxiYWNrPXRydWUmY2xpZW50X25hbWU9T2lkY0Nsa >>>>>> WVudCIsInN0YXRlIjoibGwxd1lGMnRqbmpMNEZRb2hUTmRqejA5NU90WGRZR >>>>>> 1VhOGI0cXNVOXNFNCJ9fQ.3zHWytk5YI2Uz-Ugl5RslDa3NrzkgA8g2ToXRuzfOgU >>>>>> Host:aegle-keycloak.exodussa.com >>>>>> Origin:https://aegle-keycloak.exodussa.com >>>>>> Referer:https://aegle-keycloak.exodussa.com/auth/realms/AEGL >>>>>> E/protocol/openid-connect/auth?response_type=code&client_id= >>>>>> aegle_knox&redirect_uri=https%3A%2F%2F83.212.114.145%3A8443% >>>>>> 2Fgateway%2Fknoxsso%2Fapi%2Fv1%2Fwebsso%3Fpac4jCallback%3Dtr >>>>>> ue%26client_name%3DOidcClient&scope=openid&state=ll1wYF2tjnj >>>>>> L4FQohTNdjz095OtXdYGUa8b4qsU9sE4 >>>>>> Upgrade-Insecure-Requests:1 >>>>>> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) >>>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 >>>>>> Query String Parameters >>>>>> code:GURA9HtMgD3qLRMQ5VWB4pIyeVbhiZaTyE-FtmeGvIM.475fff9a-dc >>>>>> e5-42ce-86d9-9433941f919d >>>>>> execution:7e0fa916-c58b-4a07-8200-f822793c5ecd >>>>>> Form Data >>>>>> username:<something> >>>>>> password:<password> >>>>>> login:Log in >>>>>> >>>>>> and then, this is the final request to the actual resource I'm >>>>>> supposed to be allowed access: >>>>>> >>>>>> Request URL:https://83.212.114.145:8443/gateway/knoxsso/api/v1/webss >>>>>> o?pac4jCallback=true&client_name=OidcClient&state=ll1wYF2tjn >>>>>> jL4FQohTNdjz095OtXdYGUa8b4qsU9sE4&code=GURA9HtMgD3qLRMQ5VWB4 >>>>>> pIyeVbhiZaTyE-FtmeGvIM.475fff9a-dce5-42ce-86d9-9433941f919d >>>>>> Request Method:GET >>>>>> Status Code:500 Server Error >>>>>> Remote Address:83.212.114.145:8443 >>>>>> Referrer Policy:no-referrer-when-downgrade >>>>>> Response Headers >>>>>> Cache-Control:must-revalidate,no-cache,no-store >>>>>> Connection:close >>>>>> Content-Length:319 >>>>>> Content-Type:text/html; charset=ISO-8859-1 >>>>>> Date:Tue, 03 Oct 2017 08:02:28 GMT >>>>>> Server:Jetty(9.2.15.v20160210) >>>>>> Set-Cookie:pac4j.session.OidcClient$attemptedAuthentication= >>>>>> ;Version=1;Domain=83.212.114.145;Secure;HttpOnly >>>>>> Request Headers >>>>>> Accept:text/html,application/xhtml+xml,application/xml;q=0.9 >>>>>> ,image/webp,image/apng,*/*;q=0.8 >>>>>> Accept-Encoding:gzip, deflate, br >>>>>> Accept-Language:en-US,en;q=0.8,el;q=0.6 >>>>>> Cache-Control:max-age=0 >>>>>> Connection:keep-alive >>>>>> Cookie:pac4j.session.pac4jRequestedUrl=AAAACAAAABAAAACgwphJ1 >>>>>> gNmSWXb5GnxdXfVCI0HdCrc3TNYgXxJmec0n9qdmZ8poE3Jb9ND24b3l9Z7C >>>>>> Jlrl6vmK7tlgQmW91lTGYE4PduRCNAyKfJ76zeIVejgKBrCD4vkVksx+9F43 >>>>>> gLxvCVihtZ7WlhmaOfeUunhp5whzZKVvUI8NtwIa66fkxfodRH485XzYQKoS >>>>>> 0MaNOu/RQbwv28PDnCvaPhashKFuK5+/LQCX0KH+r/vNBFAyij+oJV/5D9T3g==; >>>>>> pac4j.session.oidcStateAttribute=AAAACAAAABAAAADAwphJ1gNmSWX >>>>>> b5GnxdXfVCI0HdCrc3TNYnq+yXxGmEAkOvqi8ANmLzSDY8eHovwMpsei3ZH4 >>>>>> m7GEONfq6NHgkeS0vG6blmpuU9VEcUHVGAHs4vZzbV+V9DFN3NIT9gM66R/w >>>>>> WbMlbs4QkJOF3a8ZLNhvnzOczNAMvrWra7mmLGfwM6QW4KF8eP4lbn1WME8K >>>>>> 6QFeCUYK2huqneYddjaQYVX4pYQaS7MgPMvSrjwNimHU20JAIuWzorTALLc1 >>>>>> vPqbfIcbBh6JKvDZ0/z7mILTzMTvaBpP5Nxhc >>>>>> Host:83.212.114.145:8443 >>>>>> Referer:https://aegle-keycloak.exodussa.com/auth/realms/AEGL >>>>>> E/protocol/openid-connect/auth?response_type=code&client_id= >>>>>> aegle_knox&redirect_uri=https%3A%2F%2F83.212.114.145%3A8443% >>>>>> 2Fgateway%2Fknoxsso%2Fapi%2Fv1%2Fwebsso%3Fpac4jCallback%3Dtr >>>>>> ue%26client_name%3DOidcClient&scope=openid&state=ll1wYF2tjnj >>>>>> L4FQohTNdjz095OtXdYGUa8b4qsU9sE4 >>>>>> Upgrade-Insecure-Requests:1 >>>>>> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) >>>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 >>>>>> Query String Parameters >>>>>> pac4jCallback:true >>>>>> client_name:OidcClient >>>>>> state:ll1wYF2tjnjL4FQohTNdjz095OtXdYGUa8b4qsU9sE4 >>>>>> code:GURA9HtMgD3qLRMQ5VWB4pIyeVbhiZaTyE-FtmeGvIM.475fff9a-dc >>>>>> e5-42ce-86d9-9433941f919d >>>>>> >>>>>> I dont quite understand what should the proper header be like. >>>>>> >>>>>> KR, >>>>>> Nick Vidiadakis >>>>>> >>>>>> >>>>>> On Tue, Oct 3, 2017 at 8:22 AM, N. Vidiadakis <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hello to all, >>>>>>> >>>>>>> You say "you set something else in your metadata". You mean on my >>>>>>> IDP (Keycloak) or can I configure something different on knoxsso >>>>>>> topology? >>>>>>> >>>>>>> KR, >>>>>>> Nick >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 3, 2017 at 6:00 AM, Jérôme LELEU <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Indeed, the issue occurs in the Nimbus SDK inside pac4j. >>>>>>>> >>>>>>>> The client authentication is built from your metadata configuration >>>>>>>> and we only support *client_secret_post* and *client_secret_basic*. I >>>>>>>> guess you set something else in your metadata, certainly >>>>>>>> private_key_jwt. >>>>>>>> >>>>>>>> From the spec: >>>>>>>> >>>>>>>> token_endpoint_auth_methods_supportedOPTIONAL. JSON array >>>>>>>> containing a list of Client Authentication methods supported by this >>>>>>>> Token >>>>>>>> Endpoint. The options are client_secret_post, client_secret_basic, >>>>>>>> client_secret_jwt, and private_key_jwt, as described in Section 9 >>>>>>>> of OpenID Connect Core 1.0 >>>>>>>> <https://openid.net/specs/openid-connect-discovery-1_0.html#OpenID.Core> >>>>>>>> [OpenID.Core]. >>>>>>>> Other authentication methods MAY be defined by extensions. If omitted, >>>>>>>> the >>>>>>>> default is client_secret_basic -- the HTTP Basic Authentication >>>>>>>> Scheme specified in Section 2.3.1 of OAuth 2.0 >>>>>>>> <https://openid.net/specs/openid-connect-discovery-1_0.html#RFC6749> >>>>>>>> [RFC6749]. >>>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Best regards, >>>>>>>> Jérôme >>>>>>>> >>>>>>>> On Mon, Oct 2, 2017 at 9:49 PM, larry mccay <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Unfortunately, it seems that you will need to put a breakpoint in >>>>>>>>> the code at org.apache.hadoop.gateway.p >>>>>>>>> ac4j.filter.Pac4jDispatcherFilter.doFilter(Pac4jDispatcherFilter.java:205) >>>>>>>>> and walk through - hopefully into the pac4j code and nimbus to see >>>>>>>>> what is >>>>>>>>> expected and not being found. >>>>>>>>> >>>>>>>>> Explicitly adding Jerome... >>>>>>>>> >>>>>>>>> @Jerome - does this error ring any bells for you? >>>>>>>>> >>>>>>>>> On Mon, Oct 2, 2017 at 3:09 PM, N. Vidiadakis < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> I've done the modifications and unfortunately, I have the same >>>>>>>>>> results: >>>>>>>>>> >>>>>>>>>> 2017-10-02 19:06:10,559 ERROR hadoop.gateway >>>>>>>>>> (AbstractGatewayFilter.java:doFilter(69)) - Failed to execute >>>>>>>>>> filter: java.lang.IllegalArgumentException: The client >>>>>>>>>> authentication must not be null >>>>>>>>>> 2017-10-02 19:06:10,560 ERROR hadoop.gateway >>>>>>>>>> (GatewayFilter.java:doFilter(146)) - Gateway processing failed: >>>>>>>>>> javax.servlet.ServletException: java.lang.IllegalArgumentException: >>>>>>>>>> The client authentication must not be null >>>>>>>>>> javax.servlet.ServletException: java.lang.IllegalArgumentException: >>>>>>>>>> The client authentication must not be null >>>>>>>>>> at org.apache.hadoop.gateway.filter.AbstractGatewayFilter.doFil >>>>>>>>>> ter(AbstractGatewayFilter.java:70) >>>>>>>>>> at org.apache.hadoop.gateway.GatewayFilter$Holder.doFilter(Gate >>>>>>>>>> wayFilter.java:346) >>>>>>>>>> at org.apache.hadoop.gateway.GatewayFilter$Chain.doFilter(Gatew >>>>>>>>>> ayFilter.java:246) >>>>>>>>>> at org.apache.hadoop.gateway.GatewayFilter.doFilter(GatewayFilt >>>>>>>>>> er.java:140) >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> KR, >>>>>>>>>> Nick >>>>>>>>>> >>>>>>>>>> On Mon, Oct 2, 2017 at 9:57 PM, larry mccay <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Can you add the following after your discoveryUrl in the >>>>>>>>>>> knoxsso.xml: >>>>>>>>>>> >>>>>>>>>>> <param> >>>>>>>>>>> <name>oidc.useNonce</name> >>>>>>>>>>> <value>false</value> >>>>>>>>>>> </param> >>>>>>>>>>> <param> >>>>>>>>>>> <name>oidc.customParamKey1</name> 5. scope >>>>>>>>>>> <value>scope</value> >>>>>>>>>>> </param> >>>>>>>>>>> <param> >>>>>>>>>>> <name>oidc.customParamValue1</name> >>>>>>>>>>> <value>openid</value> >>>>>>>>>>> </param> >>>>>>>>>>> >>>>>>>>>>> In the testing that I did the the idp did not require the email >>>>>>>>>>> and profile scopes that are requested by default by pac4j. >>>>>>>>>>> Therefore, the >>>>>>>>>>> customParam was being used here to limit the scopes to just openid. >>>>>>>>>>> >>>>>>>>>>> I happen to have the useNonce param in mine - so you might as >>>>>>>>>>> well try that too. >>>>>>>>>>> >>>>>>>>>>> On Mon, Oct 2, 2017 at 2:49 PM, N. Vidiadakis < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Larry, >>>>>>>>>>>> >>>>>>>>>>>> You can find attached the topologies and the stack trace. >>>>>>>>>>>> >>>>>>>>>>>> thank you in advance, >>>>>>>>>>>> Nick >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Oct 2, 2017 at 9:34 PM, larry mccay <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Nick - >>>>>>>>>>>>> >>>>>>>>>>>>> Can you please provide your topologies that you are using for >>>>>>>>>>>>> both sandbox.xml and knoxsso.xml? >>>>>>>>>>>>> >>>>>>>>>>>>> I have tested OIDC usecase before and would like to compare >>>>>>>>>>>>> the configuration that you have - I did not try it against >>>>>>>>>>>>> Keycloak but it >>>>>>>>>>>>> should be generic OIDC. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, can you provide the full stacktrace from the log? >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> --larry >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Oct 2, 2017 at 2:22 PM, N. Vidiadakis < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hello to all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm relatively new to the whole Hadoop/KNOX ecosystem but I'm >>>>>>>>>>>>>> appointed with relatively more complicated task: integrate KNOX >>>>>>>>>>>>>> with an Idp >>>>>>>>>>>>>> and specifically with a Keycloak installation which uses OpenID. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've tried following the User Guide and my current state is I >>>>>>>>>>>>>> get redirected to the Keycloak Login portal, I enter my >>>>>>>>>>>>>> credentials and >>>>>>>>>>>>>> then get back to the KnoxSSO urls with an error 500. The log >>>>>>>>>>>>>> files contain: >>>>>>>>>>>>>> >>>>>>>>>>>>>> gateway.log: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Caused by: java.lang.IllegalArgumentException: The client >>>>>>>>>>>>>> authentication must not be null >>>>>>>>>>>>>> at com.nimbusds.oauth2.sdk.TokenR >>>>>>>>>>>>>> equest.<init>(TokenRequest.java:87) >>>>>>>>>>>>>> at com.nimbusds.oauth2.sdk.TokenR >>>>>>>>>>>>>> equest.<init>(TokenRequest.java:112) >>>>>>>>>>>>>> >>>>>>>>>>>>>> gateway-audit.log: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 17/10/02 18:07:17 ||287109de-665e-469e-811e-8991 >>>>>>>>>>>>>> 550b27e6|audit|91.138.248.128|WEBHDFS||||access|uri|/gateway >>>>>>>>>>>>>> /sandbox/webhdfs/v1/?op=GETHOMEDIRECTORY|unavailable|Request >>>>>>>>>>>>>> method: GET >>>>>>>>>>>>>> 17/10/02 18:07:17 ||287109de-665e-469e-811e-8991 >>>>>>>>>>>>>> 550b27e6|audit|91.138.248.128|WEBHDFS||||access|uri|/gateway >>>>>>>>>>>>>> /sandbox/webhdfs/v1/?op=GETHOMEDIRECTORY|success|Response >>>>>>>>>>>>>> status: 302 >>>>>>>>>>>>>> 17/10/02 18:07:17 ||a17b49de-dcf6-4bf1-90b1-6f25 >>>>>>>>>>>>>> 51e5380f|audit|91.138.248.128|KNOXSSO||||access|uri|/gateway >>>>>>>>>>>>>> /knoxsso/api/v1/websso?originalUrl=https://83.212.114.145:84 >>>>>>>>>>>>>> 43/gateway/sandbox/webhdfs/v1/?op=GETHOMEDIRECTORY|unavailab >>>>>>>>>>>>>> le|Request method: GET >>>>>>>>>>>>>> 17/10/02 18:07:17 ||a17b49de-dcf6-4bf1-90b1-6f25 >>>>>>>>>>>>>> 51e5380f|audit|91.138.248.128|KNOXSSO||||access|uri|/gateway >>>>>>>>>>>>>> /knoxsso/api/v1/websso?originalUrl=https://83.212.114.145:84 >>>>>>>>>>>>>> 43/gateway/sandbox/webhdfs/v1/?op=GETHOMEDIRECTORY|success|R >>>>>>>>>>>>>> esponse status: 302 >>>>>>>>>>>>>> 17/10/02 18:07:17 ||0cef72c6-e010-4275-a309-6612 >>>>>>>>>>>>>> 4e7a1cdb|audit|91.138.248.128|KNOXSSO||||access|uri|/gateway >>>>>>>>>>>>>> /knoxsso/api/v1/websso?pac4jCallback=true&client_name=OidcCl >>>>>>>>>>>>>> ient&state=8_-8Ni4pQynijY1ov26rNhXAYkWBWx10GyqJSnZHXYA&code= >>>>>>>>>>>>>> dFHZBD2zpFbZYFLUArBdHaA1Nb_uEoDzHhULpehX7Sg.cbc5dae7-3532-4e >>>>>>>>>>>>>> 56-a530-de1ea90b078a|unavailable|Request method: GET >>>>>>>>>>>>>> 17/10/02 18:07:17 ||0cef72c6-e010-4275-a309-6612 >>>>>>>>>>>>>> 4e7a1cdb|audit|91.138.248.128|KNOXSSO||||access|uri|/gateway >>>>>>>>>>>>>> /knoxsso/api/v1/websso?pac4jCallback=true&client_name=OidcCl >>>>>>>>>>>>>> ient&state=8_-8Ni4pQynijY1ov26rNhXAYkWBWx10GyqJSnZHXYA&code= >>>>>>>>>>>>>> dFHZBD2zpFbZYFLUArBdHaA1Nb_uEoDzHhULpehX7Sg.cbc5dae7-3532-4e >>>>>>>>>>>>>> 56-a530-de1ea90b078a|failure| >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, Keycloak does not report something out of the ordinary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My question is if and how to further debug this. I also >>>>>>>>>>>>>> wanted to try a bearer-only configuration but the documentation >>>>>>>>>>>>>> is not >>>>>>>>>>>>>> clear enough for the configuration. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please. Help. >>>>>>>>>>>>>> >>>>>>>>>>>>>> KR, >>>>>>>>>>>>>> Nick Vidiadakis >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
