Re: [keycloak-user] CORS ?Access-Control-Allow-Origin? missing

Hi Jan, If I comment out the jQuery "crossDomain: true" and "xhrFields: {withCredentials: true}" attributes of the XHR object then I do see the OPTIONS header in the web browser console. If I include the attributes I don't see OPTIONS. Is it possible preflight isn't needed if you've configured your client to use crossDomain? If forgot to include in my last email the final request HTTP status response code: it is 303. Is that a clue? What about all of the CORS options such as cors-max-age, cors-allowed-headers, cors-allowed-methods, etc. I am not including them in Wildfly standalone.xml currently. Are they needed to make this work? It doesn't seem to make a difference when experimenting, but I'm not sure what values to use... Thanks, Ryan ----- Original Message ----- From: "Jan Garaj" <jan.garaj(a)gmail.com&gt; To: "keycloak-user" <keycloak-user(a)lists.jboss.org&gt; Sent: Wednesday, August 15, 2018 3:36:24 AM Subject: Re: [keycloak-user] CORS ?Access-Control-Allow-Origin? missing Hi, Actually, Access-Control-Allow-Origin is not missing, because it should be available in the preflight (OPTIONS) response and not in GET/POST response. My assumption is that 3.4.2+ Keycloak CORS implementation is broken and it doesn't support any JS cross-domain access at the moment. More details: https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro... You can find this CORS problem also on StackOverflow: https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_qu... Workaround: downgrade to 3.4.2- and use insecure "Web Origins": "*" *Jan Garaj* Web: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jangaraj.com&... / https://urldefense.proofpoint.com/v2/url?u=http-3A__monitoringartist.com&... LinkedIn: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_j... On Wed, Aug 15, 2018 at 8:09 AM <keycloak-user-request(a)lists.jboss.org&gt; wrote: > Send keycloak-user mailing list submissions to > keycloak-user(a)lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail... > or, via email, send a message with subject or body 'help' to > keycloak-user-request(a)lists.jboss.org > > You can reach the person managing the list at > keycloak-user-owner(a)lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of keycloak-user digest..." > Today's Topics: > > 1. CORS ?Access-Control-Allow-Origin? missing (Ryan Slominski) > 2. How to force client to use PKCE code exchange? (Eric B) > 3. Client roles in Access Token (Henning Waack) > > > > ---------- Forwarded message ---------- > From: Ryan Slominski <ryans(a)jlab.org&gt; > To: keycloak-user <keycloak-user(a)lists.jboss.org&gt; > Cc: > Bcc: > Date: Tue, 14 Aug 2018 16:21:54 -0400 (EDT) > Subject: [keycloak-user] CORS ‘Access-Control-Allow-Origin’ missing > Hi Keycloak Users, > > I'm attempting to save my users a few button clicks by automatically > trying brokered identity providers in the background with AJAX requests > before redirecting them to the Keycloak login form (AJAX requests using > kc_idp_hint parameter). In most cases users will already be logged into > one of the brokered identity providers (the client is often on one of > several SPNEGO protected subnets) and instead of showing users the login > form with buttons to try the brokered providers manually one by one I was > hoping to simply do it for them in the background and when directed to the > login form for the realm the common case would be for users to be > immediately redirected back because they're logged in already. I'm using > the Wildfly client adapters (Java servlet container managed security) > configured as confidential clients. I have the client "Web Origins" set to > "*". In the Wildfly standalone.xml I have the clients configured with > "<enable-cors>true</enable-cors>". I'm using Keycloak! > 4.1.0. On the client side I'm using jQuery and have "crossDomain: true" > and "xhrFields:{withCredentials: true}" set on the XHR object. The > keycloak server still doesn't respond with a Access-Control-Allow-Origin > header though so the login fails. It works if not using AJAX. The > network trace of an AJAX request from the web browser console looks like: > > --- Request 1 --- > GET > https://urldefense.proofpoint.com/v2/url?u=https-3A__myhost.example.com_m... > Host: myhost.example.com > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Firefox/52.0 > Accept: text/html, */*; q=0.01 > Accept-Language: en-US,en;q=0.5 > Accept-Encoding: gzip, deflate, br > Referer: https://urldefense.proofpoint.com/v2/url?u=https-3A__myhost.example.com_m... > Cookie: OAuth_Token_Request_State=<REDACTED>; JSESSIONID=<REDACTED>.myhost > Connection: keep-alive > > --- Response 1 --- > Cache-Control: no-cache, no-store, must-revalidate > Connection: Keep-Alive > Content-Length: 0 > Date: Tue, 14 Aug 2018 19:48:46 GMT > Expires: 0 > Keep-Alive: timeout=5, max=100 > Location: > https://urldefense.proofpoint.com/v2/url?u=https-3A__keycloak1.example.co... > <REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid > Pragma: no-cache > Server: WildFly/11 > Set-Cookie: OAuth_Token_Request_State=<REDACTED>; HttpOnly > X-Powered-By: Undertow/1 > > --- Request 2 --- > GET > https://urldefense.proofpoint.com/v2/url?u=https-3A__keycloak1.example.co... > <REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid > Host: keycloak1.example.com > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Firefox/52.0 > Accept: text/html, */*; q=0.01 > Accept-Language: en-US,en;q=0.5 > Accept-Encoding: gzip, deflate, br > Referer: https://urldefense.proofpoint.com/v2/url?u=https-3A__myhost.example.com_m... > Origin: https://urldefense.proofpoint.com/v2/url?u=https-3A__myhost.example.com&a... > Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; KC_RESTART=<REDACTED> > Connection: keep-alive > > --- Response 2 --- > Status: 401 > Cache-Control: no-store, must-revalidate, max-age=0 > Connection: Keep-Alive > Content-Length: 615 > Content-Type: text/html;charset=UTF-8 > Date: Tue, 14 Aug 2018 19:48:48 GMT > Keep-Alive: timeout=5, max=100 > Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips > mod_auth_kerb/5.4 PHP/7.1.18 mod_wsgi/3.4 Python/2.7.5 > Set-Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; Version=1; > Path=/auth/realms/myrealm/; Secure; HttpOnly > KC_RESTART=<REDACTED>; Version=1; Path=/auth/realms/myrealm/; Secure; > HttpOnly > WWW-Authenticate: Negotiate > > --- Request 3 --- > GET > https://urldefense.proofpoint.com/v2/url?u=https-3A__keycloak1.example.co... > <REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid > Host: keycloak1.example.com > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Firefox/52.0 > Accept: text/html, */*; q=0.01 > Accept-Language: en-US,en;q=0.5 > Accept-Encoding: gzip, deflate, br > Referer: https://urldefense.proofpoint.com/v2/url?u=https-3A__myhost.example.com_m... > Origin: https://urldefense.proofpoint.com/v2/url?u=https-3A__myhost.example.com&a... > Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; KC_RESTART=<REDACTED> > Connection: keep-alive > Authorization: Negotiate <REDACTED> > > --- Response 3 --- > Cache-Control: no-store, must-revalidate, max-age=0 > Connection: Keep-Alive > Content-Length: 0 > Date: Tue, 14 Aug 2018 19:48:48 GMT > Keep-Alive: timeout=5, max=99 > Location: > https://urldefense.proofpoint.com/v2/url?u=https-3A__keycloak1.example.co... > <REDACTED>&client_id=client1&tab_id=FP3hTW-bfQ8 > Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips > mod_auth_kerb/5.4 PHP/7.1.18 mod_wsgi/3.4 Python/2.7.5 > Set-Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; Version=1; > Path=/auth/realms/myrealm/; Secure; HttpOnly > KC_RESTART=<REDACTED>; Version=1; Path=/auth/realms/myrealm/; Secure; > HttpOnly > > Notice I must redirect off a protected URL on my client app since Wildfly > client adapter only works on pages which are explicitly protected by the > container managed security. Also notice in the third and final request the > response is missing the Access-Control-Allow-Origin header, which results > in the error in the browser web console and the process ending. Any ideas? > > Thanks, > > Ryan > > > > > > ---------- Forwarded message ---------- > From: Eric B <ebenzacar(a)gmail.com&gt; > To: keycloak-user(a)lists.jboss.org > Cc: > Bcc: > Date: Tue, 14 Aug 2018 23:23:57 -0400 > Subject: [keycloak-user] How to force client to use PKCE code exchange? > I'm using keycloak 3.4.3. Is there a way in the client configuration to > require PKCE code exchange? I can't seem to find an option that would > require to support this vs just the standard code exchange flow. > > Thanks > > Eric > > > > > ---------- Forwarded message ---------- > From: Henning Waack <henning.waack(a)codecentric.de&gt; > To: keycloak-user(a)lists.jboss.org > Cc: > Bcc: > Date: Wed, 15 Aug 2018 09:08:41 +0200 > Subject: [keycloak-user] Client roles in Access Token > Dear all. > > Using KC 4.2.1, I get the following access token for a "Service Account > User": > > { > "jti": "af460ad9-e436-481f-aa4c-2d0ee0a19878", > "exp": 1534251578, > "nbf": 0, > "iat": 1534251278, > "iss": " https://urldefense.proofpoint.com/v2/url?u=https-3A__xxx_auth_realms_NAK&... ", > "aud": "nak-portal", > "sub": "f19b3205-1f3c-4a7e-8e76-c5d8e47ef0e4", > "typ": "Bearer", > "azp": "nak-portal", > "auth_time": 0, > "session_state": "a47e50aa-2ed2-40fa-9ba7-453d5632ced0", > "name": "nak portal", > "given_name": "nak", > "family_name": "portal", > "preferred_username": "service-account-nak-portal", > "email": &quot;service-account-nak-portal(a)placeholder.de&quot;, > "email_verified": true, > "acr": "1", > "allowed-origins": [ > " https://urldefense.proofpoint.com/v2/url?u=http-3A__dummy-3A8008&d=Dw... " > ], > "realm_access": { > "roles": [ > "source_system" > ] > }, > "resource_access": { > "realm-management": { > "roles": [ > "manage-users", > "view-users", > "query-clients", > "query-groups", > "query-users" > ] > } > }, > "scope": "email profile", > "clientId": "nak-portal", > "clientHost": "80.242.181.71", > "clientAddress": "80.242.181.71", > "client_id": "nak-portal", > "username": "service-account-nak-portal", > "active": true > } > > Please note the five realm-management client roles. Problem is that for the > given service account I have assigned many more roles, please see attached > screenshot > > Why don't I see all effective roles (or assigned roles) in my access token? > Interestingly enough I am also missing some of my realm roles. I have > mapped 4 realm roles, but in the token I only have 1. Am I missing > something? > > Thanks in advance, greetings > > Henning > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail... _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...