August 2018 - keycloak-user - Jboss List Archives

help with getting users from angular app

by paolo lizarazu

Hi list, I have an angular app that is configured to login with keycloak, I have configured web-origin and the login is working well, now I want to get all the users from my realm and i am calling to http://<host>:<port>/auth/admin/realmns/<realm_name>/users? but this is answering with 404 and error in console for cors. zone.js:2969 OPTIONS http://<host>:<port>/auth/ admin/realmns/<realm_name>/users ? 404 (Not Found) scheduleTask @ zone.js:2969 ZoneDelegate.scheduleTask @ zone.js:407 ...... localhost/:1 Failed to load http://<host>:<port>/auth/ admin/realmns/<realm_name>/users?: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access. any help will be appreciate.

5 years, 9 months

1
0
0 / 0

Re: [keycloak-user] Problem Integration with OAuth2 provider

by Christian Neudert

Hello Graham, Maybe a little help: I remember a similar case in which the client-secret was wrong and the response that Keycloak got, was empty. Keycloak then didn't handle it as error, just went on and found no token. Best regards, Christian Neudert On 15.08.18, 00:55, "keycloak-user-bounces(a)lists.jboss.org on behalf of Graham Burgess" <keycloak-user-bounces(a)lists.jboss.org on behalf of graham.burgess(a)razer.com> wrote: I am trying to use Keycloak to broker our internally managed OAuth2 provider. I am unable to get it complete the "First Broker Login" workflow. The logs show "No token from server" as an error but I have thus far being able to get my Google-fu to help me figure out what the issue might be. I even went as far as looking at the code based on the stack trace and that would suggest that it is looking for an id_token, but my understanding for response_type=code as chosen by Keycloak, id_token isn't returned. I suspect I am doing something wrong but I don't know what and I am at a point that I don't know where to look to figure it out. I have looked at the different requests as they go through the workflow and can see all the redirects, etc. but it hasn't shown anything that has help me either. Anyone have any suggestions on how to proceed with troubleshooting this issue? Best regards, Graham Burgess RΛZΞR|stormmore Sr. DevOps Engineer (USA) Email: graham.burgess(a)razer.com DID: (415) 374 0639 [http://assets.razerzone.com/email/email-sig.jpg] Razer.com<https://www.razer.com/> | Razer Game Store<https://gamestore.razer.com/> | Razer Insider<https://insider.razer.com/> | Razer zVault<https://zvault.razer.com/> [https://upload.wikimedia.org/wikipedia/commons/thumb/c/c2/F_icon.svg/200p...]<https://www.facebook.com/Razer> [Twitter_Social_Icon_Rounded_Square_Color] <https://twitter.com/Razer> [glyph-logo_May2016] <https://www.instagram.com/razer/> [youtube_social_squircle_red] <https://www.youtube.com/Razer?sub_confirmation=1> Razer Inc. (San Francisco) 201 3rd Street, Suite 900 San Francisco CA 94103, USA Tel: +1 (415) 266 5300 Razer Inc. Stock Code: 1337.HK IMPORTANT NOTICE: This e-mail may be confidential, legally privileged or otherwise protected from disclosure. If you are not an intended recipient, do not copy, distribute or use its contents. Do inform the sender that you have received the message in error and delete it from your system. E-mails are not secure and may suffer errors, computer viruses, delay, interception and amendment. Razer accepts neither risk nor liability for any damage or loss caused by this e-mail. To the extent permitted by applicable law, Razer reserves the right to retain, monitor and intercept e-mails to and from its systems. ________________________________ [https://www.actaport.de/images/doksafe_mailclosing_actaport.jpg]<https://www.actaport.de?utm_source=email&utm_medium=mail_disclaimer&utm_c...> Kanzleisoftware für moderne Anwälte Kostenlos testen unter www.actaport.de<https://www.actaport.de?utm_source=email&utm_medium=mail_disclaimer&utm_c...> ________________________________ [https://www.actaport.de/images/doksafe_logo_200.png] dokSAFE GmbH Goethestraße 1 04109 Leipzig www.doksafe.de<https://www.doksafe.de?utm_source=email&utm_medium=mail_disclaimer&utm_ca...> ________________________________ Sitz der Gesellschaft: Goethestraße 1, 04109 Leipzig Amtsgericht Leipzig HRB 32536, Geschäftsführer Steffen Scholz, Dr. Michael Schäfer ________________________________ Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. ________________________________ This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

5 years, 9 months

2
3
0 / 0

Re: [keycloak-user] How to logout

by Ryan Slominski

Two issues: (1) Wildfly client adapter doesn't detect when a user is logged into Keycloak on pages in which HttpServletRequest.isUserInRole() method is used to programmatically determine who sees what until after hitting a declaratively protected (web.xml) page first. Wildfly client adapter assumes all pages which use isUserInRole are declaratively protected, but that is not always true (and essentially never true in my case). This means when jumping from one application to another you lose your SSO. (2) Trying to switch users in an environment where it is unknown whether you are logged in or not results in surprise logins as the previous account when you really want to enter new credentials Essentially all my application pages show something no matter if you are logged in or not, but if you are logged in you see extra stuff like edit buttons. When working in a group around a computer and someone asks to switch users (login as admin or move over and let me show you scenarios) confusion ensues as the application might show the user as not logged in, but then attempting to login detects existing token and skips login form. Now user must logout and try again. ----- Original Message ----- From: "Stan Silvert" <ssilvert(a)redhat.com> To: "Ryan Slominski" <ryans(a)jlab.org> Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org> Sent: Wednesday, August 15, 2018 4:04:03 PM Subject: Re: [keycloak-user] How to logout On 8/15/2018 3:27 PM, Ryan Slominski wrote: > Hi Stan, > If you have multiple applications you can get out-of-sync. If you open application A in one browser tab, login, and then navigate to application B in another browser tab then application B is now out of sync with keycloak until you hit a "protected" page. The problem arises because I use programmatic security instead of declarative security: I don't understand why this matters. If you are not going to a protected page in application B then why do you care if you are logged into Keycloak? I guess I'm not understanding your use case. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_tut... > > And it looks like the Wildfly client adapter doesn't handle users of programmatic security in that it doesn't detect if a SSO token exists on pages which are not declaratively protected (actually programmatic security doesn't work at all with the Keycloak adapter and I am faking it by redirecting users off of a dummy declaratively protected URL). It might be possible to have a Servlet filter do a check with the keycloak server on each request, but that would be costly. The JavaScript client has a huge advantage because it can watch the keycloak cookie presence via a hidden iframe. In fact, I realize now exposing the confidential client secret in a form client side is not a good idea. It seems like to do what I want (track SSO state across multiple tabs and multiple applications) I might have to actually have two "clients" per application: (1) on the web server side and (2) another on the browser client side. The browser client side can then detect the actual state of SSO. Or maybe I can have a single JavaScript client that is shared among multiple server side Keycloak clients and handles tracking SSO state and provides the information as a service. Maybe this is built-in to keycloak server itself? > > Ryan > > > > ----- Original Message ----- > From: "Stan Silvert" <ssilvert(a)redhat.com> > To: "Ryan Slominski" <ryans(a)jlab.org> > Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org> > Sent: Wednesday, August 15, 2018 3:02:18 PM > Subject: Re: [keycloak-user] How to logout > > Why is your client out of sync with the keycloak server? If you are > building a servlet-based application (JSF, JSP, Struts, etc.), then why > not use the WildFly adapter in the JEE way as described in the Keycloak > documentation? The WildFly Keycloak adapter takes care of all the hard > stuff for you. > > On 8/15/2018 9:50 AM, Ryan Slominski wrote: >> Hi Stan, >> The documentation doesn't mention this, but it seems the logout URL should be a POST, not a GET request. Is that true? >> >> So, I'm trying to create an HTML logout form with method post and action to the documented logout URL. The form has a submit button and two hidden fields: "client_id" and "client_secret". Clicking the submit button results in the following JSON response from the keycloak server: >> >> {"error":"invalid_request","error_description":"No refresh token"} >> >> So, I guess I need a third field, something like "refresh_token"? How would I get a refresh token? Remember I'm using the Wildfly client adapter and in my scenario the client is out-of-sync with the keycloak server (the user is logged into keycloak, but not the local client). >> >> Thanks, >> >> Ryan >> >> ----- Original Message ----- >> From: "Stan Silvert" <ssilvert(a)redhat.com> >> To: "keycloak-user" <keycloak-user(a)lists.jboss.org> >> Sent: Monday, August 13, 2018 7:15:15 PM >> Subject: Re: [keycloak-user] How to logout >> >> HttpServletRequest.logout() should not be a no-op. It was implemented a >> long time ago: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro... >> >> If there is an issue with it you should report it in JIRA. >> >> Stan >> >> On 8/13/2018 4:19 PM, Ryan Slominski wrote: >>> Hi Keycloak Users, >>> >>> I'm using the Wildfly client adapter and trying to logout of Keycloak, even if a client application container doesn't think it is logged in. This is a problem because login state with Keycloak and login state with JSESSION_ID in servlet container are two separate things that can get out-of-sync. The documentation says you can logout in one of two ways: >>> >>> 1. Call HttpServletRequest.logout() >>> 2. Navigate to URL https://urldefense.proofpoint.com/v2/url?u=http-3A__auth-2Dserver_auth_re... {realm-name}/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri >>> >>> See: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.keycloak.org_doc... >>> >>> The first appears to be a no-op because the Java container itself isn't logged in, in this case. This does work if the client container is aware that it is logged in, but doesn't otherwise. The second also doesn't seem to do anything and just redirects back to redirect_uri. Any tips? >>> >>> A forceful logout is useful in the scenario when one client (client A) logs into Keycloak, and a different client (cilent B) wants to forcefully logout as to switch users. In this scenario client B doesn't think it is logged in because the client adapter is using container managed security with JSESSIONID, and locally the client isn't logged in. However if a login was attempted it would succeed automatically without prompting for a username and password and therefore the user wouldn't get a chance to provide an alternate username. A switch user ability is useful when users need to login with separate admin credentials or also in scenarios where a user says "move over and I'll drive" to a colleague. >>> >>> Thanks, >>> >>> Ryan >>> _______________________________________________ >>> 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...

5 years, 9 months

2
3
0 / 0

UMA vs OAuth

by Dmitry Pichugin

Good day! We are using Keyclaok in our project, have installed version 4.2.1. Our task: - integration with API gateway and use KeyCloak for resources protect. We would be to use "Client Credentials Flow" from OAuth specs. But during version 4, KeyCloak does not support OAuth and is recommended to apply UMA 2.0. Yes, the differences between UMA and OAuth not huge, as a request and response(JWT token) formats, UMA has specific logic with RPT-token etc and UMA gives some advantages(we do not have the plan to use it). We try to make a request in OAuth specs but got the error. Why does KeyCloak not support OAuth and UMA 2.0 same time? Do you have some specific reasons for this? Thank you! Best regards. Dmitry Pichugin.

5 years, 9 months

2
4
0 / 0

Admin access token

by Yegui Cai

Hi all. I am using the admin REST api to obtain an access token using curl: curl --insecure -i --request POST https://127.0.0.1:8666/auth/realms/master/protocol/openid-connect/token --header 'Accept: application/json' --header 'Content-Type: application/x-www-form-urlencoded' --data 'grant_type=password&username=admin&password=admin&client_id=admin-cli' The problem is after my standalone Keycloak running for a while (in between I keep curling access token), I can not get token anymore. The out put of curl is: {"error":"invalid_grant","error_description":"Invalid user credentials"}% >From TRACE level log, I read the following: 2018-08-16 14:42:23,438 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (default task-3) new JtaTransactionWrapper 2018-08-16 14:42:23,439 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (default task-3) was existing? false 2018-08-16 14:42:23,454 TRACE [org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory] (default task-3) Create JpaConnectionProvider 2018-08-16 14:42:23,457 TRACE [org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-3) by id cache hit: master 2018-08-16 14:42:23,495 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-3) AUTHENTICATE CLIENT 2018-08-16 14:42:23,497 TRACE [org.keycloak.authentication.ClientAuthenticationFlow] (default task-3) Using executions for client authentication: [33858fd1-64d3-42ae-8713-7a98e7e83700, 63bca01e-0342-4150-9b9c-7e7ceaeda8c6, 9b46d8e9-0331-4554-8d84-0ad8d5944b3e] 2018-08-16 14:42:23,497 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (default task-3) client authenticator: client-secret 2018-08-16 14:42:23,510 TRACE [org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-3) adding client by name cache miss: admin-cli 2018-08-16 14:42:23,515 TRACE [org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-3) client by id cache hit: admin-cli 2018-08-16 14:42:23,516 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (default task-3) client authenticator SUCCESS: client-secret 2018-08-16 14:42:23,517 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (default task-3) Client admin-cli authenticated by client-secret 2018-08-16 14:42:23,519 DEBUG [org.keycloak.models.sessions.infinispan.InfinispanAuthenticationSessionProviderFactory] (default task-3) [null] Registered cluster listeners 2018-08-16 14:42:23,523 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: ADD on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,527 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,528 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,528 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,529 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,529 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,530 TRACE [org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-3) client by id cache hit: admin-cli 2018-08-16 14:42:23,530 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-3) AUTHENTICATE ONLY 2018-08-16 14:42:23,532 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,533 TRACE [org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-3) client by id cache hit: admin-cli 2018-08-16 14:42:23,534 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) processFlow 2018-08-16 14:42:23,534 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) check execution: direct-grant-validate-username requirement: REQUIRED 2018-08-16 14:42:23,534 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) authenticator: direct-grant-validate-username 2018-08-16 14:42:23,534 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) invoke authenticator.authenticate: direct-grant-validate-username 2018-08-16 14:42:23,535 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,535 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) getUserByUsername: admin 2018-08-16 14:42:23,535 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) query null 2018-08-16 14:42:23,583 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,583 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) authenticator SUCCESS: direct-grant-validate-username 2018-08-16 14:42:23,584 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:23,584 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) check execution: direct-grant-validate-password requirement: REQUIRED 2018-08-16 14:42:23,584 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) authenticator: direct-grant-validate-password 2018-08-16 14:42:23,584 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) getuserById b0942806-9744-4571-9216-d9fb57bd9d2f 2018-08-16 14:42:23,584 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) return managedusers 2018-08-16 14:42:23,584 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) invoke authenticator.authenticate: direct-grant-validate-password 2018-08-16 14:42:23,584 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) getuserById b0942806-9744-4571-9216-d9fb57bd9d2f 2018-08-16 14:42:23,584 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) return managedusers 2018-08-16 14:42:24,010 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) authenticator SUCCESS: direct-grant-validate-password 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:24,010 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) check execution: direct-grant-validate-otp requirement: OPTIONAL 2018-08-16 14:42:24,010 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) authenticator: direct-grant-validate-otp 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) getuserById b0942806-9744-4571-9216-d9fb57bd9d2f 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) return managedusers 2018-08-16 14:42:24,010 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) invoke authenticator.authenticate: direct-grant-validate-otp 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) getuserById b0942806-9744-4571-9216-d9fb57bd9d2f 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) return managedusers 2018-08-16 14:42:24,010 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-3) authenticator ATTEMPTED: direct-grant-validate-otp 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.sessions.infinispan.InfinispanKeycloakTransaction] (default task-3) Adding cache operation: REPLACE on d43ccba6-2640-48a6-9c21-0f777b2fd972 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) getuserById b0942806-9744-4571-9216-d9fb57bd9d2f 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) return managedusers 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) getuserById b0942806-9744-4571-9216-d9fb57bd9d2f 2018-08-16 14:42:24,010 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) return managedusers 2018-08-16 14:42:24,014 DEBUG [org.keycloak.authentication.requiredactions.VerifyEmail] (default task-3) User is required to verify email 2018-08-16 14:42:24,014 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) getuserById b0942806-9744-4571-9216-d9fb57bd9d2f 2018-08-16 14:42:24,015 TRACE [org.keycloak.models.cache.infinispan.UserCacheSession] (default task-3) registered for invalidation return delegate 2018-08-16 14:42:24,017 TRACE [org.keycloak.events] (default task-3) type=LOGIN_ERROR, realmId=master, clientId=admin-cli, userId=null, ipAddress=127.0.0.1, error=resolve_required_actions, auth_method=openid-connect, grant_type=password, client_auth_method=client-secret, username=admin, requestUri= https://127.0.0.1:8666/auth/realms/master/protocol/openid-connect/token, cookies=[] 2018-08-16 14:42:24,027 TRACE [org.keycloak.services.resources.Cors] (default task-3) No origin header ignoring 2018-08-16 14:42:24,028 TRACE [org.keycloak.services.resources.Cors] (default task-3) No origin header ignoring 2018-08-16 14:42:24,028 TRACE [org.keycloak.services.resources.Cors] (default task-3) No origin header ignoring 2018-08-16 14:42:24,030 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (default task-3) JtaTransactionWrapper commit 2018-08-16 14:42:24,032 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (default task-3) JtaTransactionWrapper end 2018-08-16 14:42:24,034 TRACE [org.keycloak.models.cache.infinispan.UserCacheManager] (default task-3) Removed key='master.username.admin', value='UserListQuery{id='master.username.admin'realmName='master'}' from cache 2018-08-16 14:42:24,036 TRACE [org.keycloak.models.cache.infinispan.UserCacheManager] (default task-3) Removed key='b0942806-9744-4571-9216-d9fb57bd9d2f', value='org.keycloak.models.cache.infinispan.entities.CachedUser@2ae0edf1' from cache 2018-08-16 14:42:24,037 TRACE [org.keycloak.cluster.infinispan.InfinispanNotificationsManager] (default task-3) Sending event with key 5daeb51e-3aac-4c81-add1-4e24209e62b4: UserUpdatedEvent [ userId=b0942806-9744-4571-9216-d9fb57bd9d2f, username=admin, email=null ] 2018-08-16 14:42:24,065 TRACE [org.keycloak.connections.jpa.DefaultJpaConnectionProvider] (default task-3) DefaultJpaConnectionProvider close() Could it be a potential bug? Or the way I use the admin rest api is not right? Thanks a lot! Y.

5 years, 9 months

2
2
0 / 0

Keycloak availability during LDAP outage

by Hayden Fuss

Hello, In testing Keycloak's availability for certain flows/endpoints we noticed that introspecting access tokens (never tested refresh tokens) and retrieving new access tokens via a refresh token does not work if LDAP is down and being used for READ-ONLY user federation. Is this in order to guarantee consistency since LDAP is considered the source of truth, and so if its down, everything but getting certs is down? We'd like to prioritize availability over consistency in these scenarios. As a result, we were hoping to be able to guarantee tokens could still be validated/introspected by Keycloak in an LDAP outage, and new access tokens could be granted with a refresh token. That way users/clients could still function while their refresh tokens are valid, limiting the severity of an LDAP outage. Are there settings that can be tweaked to enable this? If not, does this seem like a reasonable feature request? On a similar note, can Keycloak adapters verify tokens locally only, and then periodically go to Keycloak to verify, rather than verify locally and remotely every time? Best, Hayden

5 years, 9 months

1
1
0 / 0

Problem with SAML 2.0 IDP and direct grant

by Vollertsen, Alexander (Wilken GmbH)

Hello keycloak users, we are a company developing erp-software and want to use keycloak for our SSO server. I will shortly explain our given scenario: We have our application running on a wildflyserver protected with keycloak adapter in the standalone xml. The keycloak authentification server is running in an other wildfly. Opening our application in the browser, redirecting to keycloak server and singing in is working fine. Now the IDP comes into play. We want to authenticate at the IDP and redirect over the keycloak server directly to our application without a second authentication at the keycloak server. My understanding is to use direct grant as first login flow to get a direct redirect to our application. The idp is a server from one of our customers and we are communicating over saml 2.0. Now the idp is sending a saml response and the keycloak server is responding the following output: {"error":"invalid_request","error_description":"Missing parameter: username"} The username is located in the field urn:oid:0.9.2342.19200300.100.1.1. So why can't keycloak get the username and redirect to our application? The decoded SAML response looks like this: <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_0495d5494150cf6d61dd4421a2c04efcf084c5e438" Version="2.0" IssueInstant="2018-08-16T13:26:42Z" Destination="http://qvswm-50-cs2std:20000/auth/realms/saml20-broker-authentication-rea..." InResponseTo="ID_67b3a98b-22b7-4fb3-bccf-32f9e5ee3884"><saml:Issuer>idm.ekir.de</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_0495d5494150cf6d61dd4421a2c04efcf084c5e438"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>D3xmrXVhSRsQxhxJhrqg1WPKlmo=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>OWelDbxd2wFMclqWSw6Vyn4Xm++ykDq10tDAWZtpTJXAqbcJGYvJ1oyuk7bJi7Q47R9O5CNTuFcQQIXv45J+ux4QUnGlPIosn2RjAVIX/T87Z0nVkbSfMYfkj7t/0Ol81jaH0l3q2fbLLboCXvsi7EiyZfiUTxh778zUMjphF5W19JyLdMpx3iXBptgRFOof6mJdz129SzrnlygM0EJuVbYdQLY/5YFvOqx0Ty7kubG85lKERxYbCD31w3/T/Ij0FSU/VWrhPws0qZrNiLHNfdUY0YsdT0yIP0qiHWpGovHYM3nCJJh1/XjyzD191F2gTDZXVPjGMEriFUQ0aJSrnA==</ds:SignatureValue> <ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIEMzCCAxugAwIBAgIJAJ5hbfqjs7JMMA0GCSqGSIb3DQEBBQUAMG4xCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxDzANBgNVBAcTBkFhY2hlbjEXMBUGA1UEChMOc3luYWl4IElUIEdtYkgxETAPBgNVBAsTCFNlY3VyaXR5MRQwEgYDVQQDEwtpZG0uZWtpci5kZTAeFw0xNjA0MjAxNTAxNDdaFw0zNjA0MjAxNTAxNDdaMG4xCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxDzANBgNVBAcTBkFhY2hlbjEXMBUGA1UEChMOc3luYWl4IElUIEdtYkgxETAPBgNVBAsTCFNlY3VyaXR5MRQwEgYDVQQDEwtpZG0uZWtpci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKFv9eW8oqkBqaQzsguz0g9OnCCNOCrIuLNWjEC1Vjb8M3pLgWKt0obvm8BtgcAOSPSJpkFsjgCwiRsymk0yOKhnPhCLrEjqDMCAWLywO5K/H5SvrBc77PCSJRT0ciCdLOonvXzxEn40YEZSwjo+vqyiWt/gLfdeFtcuc8N2nZsZKdIR5V0wwD+ZSQCLNc7bnnw85tZvf6rtxHn6eo6IqzIcYzXyFSIaO0Lrh8ZN+oj9E1YW210+hNJqWb5+/VM4IpZ3jPzgSHqcyA7PxVRMEpWYBuyPNcvGR0tkqwXew51OarUxuiyyx4kTs5wZe+h4MZExnUty2wiJYyyHjpUYBK8CAwEAAaOB0zCB0DAdBgNVHQ4EFgQUr++yKews/ztiL2MslG+rTjImjAkwgaAGA1UdIwSBmDCBlYAUr++yKews/ztiL2MslG+rTjImjAmhcqRwMG4xCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxDzANBgNVBAcTBkFhY2hlbjEXMBUGA1UEChMOc3luYWl4IElUIEdtYkgxETAPBgNVBAsTCFNlY3VyaXR5MRQwEgYDVQQDEwtpZG0uZWtpci5kZYIJAJ5hbfqjs7JMMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAAObYr07VN0dtR3QUwLNq/xii154BIa1jDgvDEgSlf3Em161pXKU+/8hvHpwQFSp4w82GtiU8gYxiRVpBR02xa0PQ9d6dWRqhVtAzJloQQWIfiH75K97VLqOt77IPTuxIry84KztPnCUKxSSYyBBZ/tlJtSdAT2ce+imFHJxnSIucJoCB7gWNI3S6IoOlN3HwNmAT2BXoXXEpFsQdFEUTnOGcmxTtXh5Mqt0v3aJv3lcITHqazIGCPuPC4sbB0iuU6eRqvUXUED6Bn7JuEZmYaZ1H5sxzHu06xa+smDDGE15UXns5CB0BlaP2r8LckcRjOsPnAzKmp3Zr6uvD/+K7Ps=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_2f00bcc88e72b831d12c3bd2cde89885036b8034ba" Version="2.0" IssueInstant="2018-08-16T13:26:42Z"><saml:Issuer>idm.ekir.de</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_2f00bcc88e72b1d12c3bd2cd885036b8034ba"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>lGcsEgEI/9gDZnc+7tbiVHKA=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>CztzEHTsWNzwKhkykPdsUP5OcXJJCy7O0VqTW+8vBsbQMg92z4QhX/yX+NvXrMS6/AaBhXS9YIsDxqp8LMqN9XHCEo+ZR2EKVZwAY005x2PxtTMoF6f+43ItekGdPscm28TyjXvh5OM5WSgux1Jx1UhMpoSqhZHTRT72KK+yEkOUwjCaqNBces4yrlgRty97HN0cyAxu+0t+3AYOujENhYbSFbiNvFUwkwcRJEAXeitkJttAGtmJ3ZBa/yhkITW2YwIjRpPw8vZHqpwDtdbjgZLFs2vSzBT4VrDQkQHvmQ+wnQEu9MFZiqT4w53OMtmvgbtM612NWouoCrs+VmGBAg==</ds:SignatureValue> <ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIEMzCCAxugAwIBAgIJAJ5hbs7JMMA0GCSqGSIb3DQEBBQUG4xCzAJBgBAYTAkRFMQwwCgYDVQQIEwNOUlcxDzANBgNAcTBkFhY2hlbjEXMBUGA1UEChMOc3luYWl4IElUIEdtYkgxETAPBgNVBAsTCFNlY3VyaXR5MRQwEgYDVQQDEwtpZG0uZWtpci5kZTAeFw0xNjA0MjAxNTAxNDdaFw0zNjA0MjAxNTAxNDdaMG4xCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxDzANBgNVBAcTBkFhY2hlbjEXMBUGA1UEChMOc3luYWl4IElUIEdtYkgxETAPBgNVBAsTCFNlY3VyaXR5MRQwEgYDVQQDEwtpZG0uZWtpci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKFv9eW8oqkBqaQzsguz0g9OnCCNOCrIuLNWjEC1Vjb8M3pLgWKt0obvm8BtgcAOSPSJpkFsjgCwiRsymk0yOKhnPhCLrEjqDMCAWLywO5K/H5SvrBc77PCSJRT0ciCdLOonvXzxEn40YEZSwjo+vqyiWt/gLfdeFtcuc8N2nZsZKdIR5V0wwD+ZSQCLNc7bnnw85tZvf6rtxHn6eo6IqzIcYzXyFSIaO0Lrh8ZN+oj9E1YW210+hNJqWb5+/VM4IpZ3jPzgSHqcyA7PxVRMEpWYBuyPNcvGR0tkqwXew51OarUxuiyyx4kTs5wZe+h4MZExnUty2wiJYyyHjpUYBK8CAwEAAaOB0zCB0DAdBgNVHQ4EFgQUr++yKews/ztiL2MslG+rTjImjAkwgaAGA1UdIwSBmDCBlYAUr++yKews/ztiL2MslG+rTjImjAmhcqRwMG4xCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxDzANBgNVBAcTBkFhY2hlbjEXMBUGA1UEChMOc3luYWl4IElUIEdtYkgxETAPBgNVBAsTCFNlY3VyaXR5MRQwEgYDVQQDEwtpZG0uZWtpci5kZYIJAJ5hbfqjs7JMMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAAObYr07VN0dtR3QUwLNq/xii154BIa1jDgvDEgSlf3Em161pXKU+/8hvHpwQFSp4w82GtiU8gYxiRVpBR02xa0PQ9d6dWRqhVtAzJloQQWIfiH75K97VLqOt77IPTuxIry84KztPnCUKxSSYyBBZ/tlJtSdAT2ce+imFHJxnSIucJoCB7gWNI3S6IoOlN3HwNmAT2BXoXXEpFsQdFEUTnOGcmxTtXh5Mqt0v3aJv3lcITHqazIGCPuPC4sbB0iuU6eRqvUXUED6Bn7JuEZmYaZ1H5sxzHu06xa+smDDGE15UXns5CB0BlaP2r8LckcRjOsPnAzKmp3Zr6uvD/+K7Ps=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml:Subject><saml:NameID SPNameQualifier="http://qvswm-50-cs2std:20000/auth/realms/saml20-broker-authentication-realm" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">94fbf27f692f840a63ea08a0eb8153ec86d022ea</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2018-08-16T13:31:42Z" Recipient="xxxxx" InResponseTo="ID_67b3a98b-22b7-4fb3-bccf-32f9e5ee3884"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore="2018-08-16T13:26:12Z" NotOnOrAfter="2018-08-16T13:31:42Z"><saml:AudienceRestriction><saml:Audience>http://qvswm-50-cs2std:20000/auth/realms/saml20-broker-authentication-realm</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2018-08-16T13:26:42Z" SessionNotOnOrAfter="2018-08-17T13:26:42Z" SessionIndex="_4e34b8713e382904ca49318f0ed93f44032b19f297"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement><saml:AttributeStatement><saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">test2.syn</saml:AttributeValue></saml:Attribute><saml:Attribute Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">syn</saml:AttributeValue></saml:Attribute><saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">test2.syn(a)ek.de</saml:AttributeValue></saml:Attribute><saml:Attribute Name="urn:oid:2.5.4.42" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">test2</saml:AttributeValue></saml:Attribute><saml:Attribute Name="mobile" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string"></saml:AttributeValue></saml:Attribute><saml:Attribute Name="urn:oid:2.5.4.20" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string"></saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response> I would appreciate to get some help from the community. Mit freundlichen Grüßen/Best regards Alexander Vollertsen Systementwickler | System Developer Systementwicklung | System Development Phone: +49 731 9650-373 | Fax: Email: Alexander.Vollertsen(a)wilken.de | Web: www.wilken.de [Bestätigung der Daten]<http://www.wilken.de/datenschutz/dsgvo/> Wilken GmbH Hörvelsinger Weg 29-31 89081 Ulm, Germany Sitz der Gesellschaft: Ulm Amtsgericht Ulm: HRB 794 Geschäftsführer: Folkert Wilken, Peter Heinz, Dr. Jörg Vogt

5 years, 9 months

1
0
0 / 0

Naming of the keycloak proxy/generic adapter

by John Doyle

We've begun calling the keycloak proxy the generic adapter. I think this is a good move, there's too many proxies. My concern with 'generic adapter' is that it's not specific enough. Users could be justified in thinking that they can proxy SAML with it in addition to OIDC. I propose that we included OIDC in the name to make it clear. Some Possibilities: OIDC Adapter Generic OIDC Adapter Universal OIDC Adapter Standalone OIDC Adapter Other ideas or preferences? ~jd

5 years, 9 months

4
3
0 / 0

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

by Ryan Slominski

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> To: "keycloak-user" <keycloak-user(a)lists.jboss.org> 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&d=Dw... / 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> 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> > To: keycloak-user <keycloak-user(a)lists.jboss.org> > 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&d... > 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&d... > 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> > 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> > 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": "service-account-nak-portal(a)placeholder.de", > "email_verified": true, > "acr": "1", > "allowed-origins": [ > "https://urldefense.proofpoint.com/v2/url?u=http-3A__dummy-3A8008&d=DwIGaQ... " > ], > "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...

5 years, 9 months

2
2
0 / 0

Re: [keycloak-user] Using Keycloak for per field authorisation

by Pedro Igor Silva

Sorry for the late reply ... On Fri, Aug 10, 2018 at 3:46 PM, Courtney Robinson < courtney.robinson(a)hypi.io> wrote: > I'm a little confused about what type A and B are. You also mentioned you >>> may have an "instance of A". Does that mean that types A and B represent >>> generic resources which policies should be enforced on instances of A and B >>> ? Are these instances user-managed resources ? >>> >> > Types A and B are GraphQL objects. If you're not familiar then just think > of them as classes A and B with only class members/fields defined. > I'm not explaining this very well I think so another way to think about it > is like this. > > By default I want to apply some global policies to classes A and B that > says for example, anyone in Organisation 1 can read/write classes A and B. > This is "system defined". > More concretely imagine classes User and Book. Two organisations Org1 and > Org2. > When we create a realm for each org, we want to tell Keycloak that some > app X has two types User and Book and any user in the current realm can > read/write fields of both User and Book within this realm. > > We also want to tell Keycloak that an "admin" (I imagine a user with some > role or in a specific group) in this realm can add policies that override > the above behaviour. > Given one or more of these admins, they can then choose to create a policy > that says "Users from site A can read/write all fields of User and Book but > users from site B can only read some fields from User and all fields from > Book". > > The other case I mentioned in my first email is where, a user in an > organisation has created e.g. a "Book" record. Under default policies only > they can see and manage this Book they created. They can then share this > book with site 2 so that users in site 2 can also read the book, they may > also share it with the whole organisation so anyone in the realm can read > it. The extension to this is when members of one site could normally only > see a subset of fields from Book but one one occasion a user shares a > single Book with one or more members giving then the permission to "manage" > this one Book. This lifts the limitation on this one instance of book > enabling the user it is shared with to access a field of Book they wouldn't > have been able to see before. > Now I see, thanks. I was imagining something like that. In Keycloak, resource can have a type [1]. A "typed" resource is a resource which owner is the resource server (when I say resource server, I mean the client application you are setting up permissions). You can define permissions to these typed resources [2] where these permissions will be considered when deciding whether or not access should be granted to other resources with the same type, where these other resources are actually instances of the "typed" resource (the class example you gave). Resource instances have users as resource owners, not the resource server. That is the difference between a typed vs resource instance. Let's take the case you mentioned as an example. You have a "Book Resource" with a type "book" and permissions associated with this book. Where policies associated with this permission only grants access to the owner of the resource. Once you have this configuration, create a resource as follows: curl -X POST \ http://localhost:8180/auth/realms/{realm}/authz/protection/resource_set \ -H 'Authorization: Bearer {access_token}' \ -H 'Content-Type: application/json' \ -d '{ "name":"Alice Book", "type": "book", "resource_scopes":["read", "manage"], "owner":"alice" }' The command above is creating a book where user "alice" is the owner. Note the "type" field defined as "book". Once you do that, if you try to use the policy evaluation tool [3] to check permissions for "alice" on resource "Alice Book", access should be granted. Note that we did not define any permission for "Alice Book" directly, permissions are being processed based on what was defined for "Book Resource". We also allow you to override permissions on a per resource instance basis. So, suppose you want to also allow some other user to access "Alice Book". You just create a permission for this resource granting access to the user you want. We also support UMA, a standard focused on privacy and resource sharing requirements [4]. We have an extension to UMA (contribution from community) that allows resource servers to define custom permissions for user-managed resources [5]. When using UMA capabilities, your users are allowed to manage their resources via Keycloak Account Service. [1] https://www.keycloak.org/docs/latest/authorization_servi ces/index.html#typed-resources [2] https://www.keycloak.org/docs/latest/authorization_servi ces/index.html#_permission_typed_resource [3] https://www.keycloak.org/docs/latest/authorization_servi ces/index.html#_policy_evaluation_overview [4] https://www.keycloak.org/docs/latest/authorization_ services/index.html#_service_user_managed_access [5] https://www.keycloak.org/docs/latest/authorization_ services/index.html#_service_authorization_uma_policy_api > > >> >> >> Regarding how the adapter (policy enforcer in particular) work. It >> verifies permissions locally in case the client is sending a bearer token >> with permissions, otherwise the adapter will query the server for >> permissions associated with resource the client is trying to access >> (mapping is based on URIs). >> > > I had a feeling. One of the reasons I'm so unclear about how to achieve > what we want is that it feels like a mixture of the auth policies Keycloak > supports is needed. > I've been thinking that for each app, default Keycloak policies are > created that e.g. allowed read only within an organisation. > Use Keycloak groups to represent "sites" e.g. offices in an organisation > and applied default policies to the groups. > Then, the key thing I thought was that I'd have to register each type and > it's fields in Keycloak as resources and then have a fixed list of scopes > read, write, update, delete, share etc > When an entry/instance (say of a Book) is shared, the model changes from > being type based to being based on the ID of the object i.e. the Book's ID > It makes sense. However, I don't think the model needs to change. Your typed resource will always be there. What you need to do is create new resources (with their corresponding types) representing those "entries/instances". > > If I understood correctly, that means the size of the token will grow with > each object shared directly with a user, surely a problem. > Not really. It depends on how you want to enforce ermissions. If you don't want to evaluate permissions all the time, you can obtain a token with some initial permissions. Then you can perform incremental authorization to obtain more permissions in addition to those previously granted. We also support limiting the number of permissions in a response from the server. [4] In next release, we are also supporting a response_mode parameter that you could use to define the format of responses from server. These formats are specially useful in case you don't want to use permissions from access tokens but invoke server to only obtain permissions. [4] https://www.keycloak.org/docs/latest/authorization_services/ index.html#_service_obtaining_permissions > In a similar vein, do I have to create an entry for every Book record in > keycloak to be able to do per book permissions? > Yes. You could use a single resource + JS policy too, but there are several issues doing that. People suggested a Resource SPI, which could be used to fetch resources from external databases ...

5 years, 9 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

keycloak-user August 2018